User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/111.0

Steps to reproduce:

1. Open two full-screen windows
2. In one of them, open the downloads panel (via the button to the right of the address bar)
3. Navigate to the other full-screen window
4. Try to open the downloads panel in that window.

Note: These steps reliably reproduce this issue on macOS; i don't have access to a Linux or Windows machine, so I don't know whether the same issue also exists on these other platforms.

Actual results:

Clicking the downloads button in the second full-screen window doesn't do anything.
You have to go back to the first window (which will cause the downloads panel there to disappear) and return to the second window, and only then will you be able to open the downloads panel.

Expected results:

Clicking the downloads button right to the address bar should always open the downloads panel in full-screen.
(This is the behaviour when interacting with multiple non-full-screen windows.)
Since returning to a full-screen window makes that window's open downloads panel disappear, the panel should probably already disappear when navigating away from that window, instead of when returning to it.

The Bugbug bot thinks this bug should belong to the 'Firefox::Downloads Panel' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

(needinfo spree, sorry, but this is bonkers and I'm kind of scared about the implications. Hopefully I'm doing something dumb wrong here)

I can reproduce. (it's quicker to repro if you flip browser.download.autohideButton to false)

I added logging to the oncommand handler for the downloads button.

If I then:

1. open 2 fullscreen windows
2. click button in window A to open the panel
3. switch to window B
4. click button again, maybe 10 times

No further logging appears in the browser toolbox / stdout.

This suggests to me there's a widget level issue here. I don't know why this (a) doesn't seem to affect other buttons and (b) wouldn't happen on other platforms (though I've not tested this).

https://searchfox.org/mozilla-central/rev/e941c8a6d49b4f62f361446de7a80214fb899186/browser/base/content/navigator-toolbox.inc.xhtml#418 would suggest this is about mousedown rather than command, despite the name of the function being onCommand.

Edit: this also means there's a workaround:

1. open 2 fullscreen windows, open button in window A with mouse
2. in window B, cmd-L to move focus to the address bar if it's not there yet
3. use [tab] and left/right arrow buttons to move focus to the downloads button
4. hit [space]

this successfully opens the downloads button in window B

I guess the issue is that we're not rolling up the popup when navigating to the other window. That seems like a missing call to RollupPopups somewhere in the cocoa code. In Linux we rollup popups on window blur. I couldn't repro this there.

Looks like this is a somewhat recent regression, pushlog:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e0cb69d5cb5acb07f911638d00381f1e2b0643b9&tochange=02862be5276fce949fad6ef1e261b3aacfc8aaf6

I don't understand why that would have caused a problem like this, if, as comment 4 suggests, this is related to whether we call RollupPopups()...

Otherwise if we become fully occluded we'll throttle the refresh driver,
which means that the panel transition won't end soon enough, and the
popuphidden event won't fire soon enough. This blocks opening other
downloads panels because of this:

https://searchfox.org/mozilla-central/rev/98397ff4eac3d32b815fbb33bff147297fb972d7/browser/components/downloads/content/downloads.js#308-310,335-340

Alternative fixes could be:

• On the front-end, remove the popup opening block on popuphiding
  rather than popuphidden.

• Doing something like this from nsCocoaWindow::DispatchOcclusionEvent,
  when we're fully occluded.

Let me know if you prefer any of those.

https://hg.mozilla.org/mozilla-central/rev/2ec8ef7e9db7

I have reproduced this issue in Beta v112.0 (RC) on Mac OS 11 and it does NOT reproduce in Windows 10.
I have verified the fix in Mac OS 11 with Nightly v113.0a1.