STR: * open a page with two download links * click one link, panel opens and download begins * click second link, download panel goes away, download does not begin Expected: click link, download starts Actual: click link, download doesn't start, have to click it twice.

(In reply to Dietrich Ayala (:dietrich) from comment #0) > STR: > > * open a page with two download links > * click one link, panel opens and download begins > * click second link, download panel goes away, download does not begin > > Expected: click link, download starts > > Actual: click link, download doesn't start, have to click it twice. Thanks for making a clear use-case for this issue. At present we're eating any click we make outside of the panel, intentionally, in particular to avoid that clicking again on the toolbar button reopens the panel. By the way it's been reported that the actual behavior with regard to eating clicks can be different, maybe it's platform-specific. Gavin, Neil, do you have any suggestion on how to handle this case better? Do we do something different for other panels? Note however that this will be less of an issue if we move to a discoverability model where we show the panel only a few times, and then never again for the same profile when a download is started.

The popup hiding handling happens early on while processing a mouse event, in platform specific code, long before we've determined what's being clicked on, so there isn't an easy fix here. We could move this code to happen later but that's a significant amount of work, although it would be useful.

I think would be easier to better define the "show where downloads go" timeframe, so that we don't show the panel at each session, but only for the first N sessions. Would be a limited annyance.

This is a much more serious problem on Linux. Not only does the panel consume mouse input to the Firefox window, it also consumes all mouse input to the desktop and other windows/applications. It's also worth pointing out that this is a problem with _all_ doorhanger panels, not just the download panel. I can reproduce this issue with Firefox 13, so I'm assuming that this has been an issue with doorhangers from the beginning. The download panel is just making this more visible. It is open much more often than other notifications, and the other notifications are usually a prompt for action so the user directly interacts with the panel rather than continuing to browse. Firefox 13+ metacity 2.30.3 glib 2.30.3 gtk+ 2.24.10 / 3.2.4 xorg-server 1.12.2 (X.org 7.7?)

fwiw, now we open the panel automatically only once, so this is a limited problem that may happen on the first download with the panel enabled.

I think the problem is so limited, now that we automatically open the panel just _once_ in all the browser life, that it's not worth complicate fixes to click handling

This is an issue that is generic to all doorhanger panels. The downloads panel may no longer be shown once per-session, but now the click-to-play doorhanger is shown once per-window-per-session.

(In reply to Matthew Turnbull [Bluefang] from comment #7) > This is an issue that is generic to all doorhanger panels. The downloads > panel may no longer be shown once per-session, but now the click-to-play > doorhanger is shown once per-window-per-session. This is a downloads panel bug, if there's a more general problem it should be filed elsewhere and expressed like that. Thanks.