1844733 - [Windows] menu popup stays at the top most after switching to another application

Status: VERIFIED FIXED

(Core :: Widget: Win32, defect, P1)

Description

[Alice0775 White]

Steps to reproduce:

1. Open app menu(hamburger menu)
2. Click on History or Bookmarks
3. Right mouse click on a history entry or a bookmark entry
4. Click on the other application button on Windows Taskbar
   or
   Click on Bottom right Show Desktop button of Windows Taskbar

Actual results:
The context menu popup stays at top most.

Expected results:
Context menu should disappear.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b3b53ca8393c116374cfe24a0a0347075472b648&tochange=0c47c1159e0a060ee709f9f8f854bfad27f86c85

Comment 1

[BugBot [:suhaib / :marco]]

:aidan, since you are the author of the regressor, bug 1292701, could you take a look?

For more information, please visit BugBot documentation.

Comment 2

[Aidan Welch]

I actually disagree that this is a bug. I intentionally changed this behavior- to allow clicking out of the window such as for copying paths or other things. This can also be useful for extensions such as MetaMask to allow copying addresses, and I'm sure many other use cases. This the behavior in Chromium, and I don't see why a behavior of closing on clicking out of the window should be expected. If there is a use case for closing the popup on clicking out of the window it shouldn't change, but for now I don't see shouldn't it does.

Comment 3

[Alice0775 White]

(In reply to Aidan Welch from comment #2)

I actually disagree that this is a bug. I intentionally changed this behavior- to allow clicking out of the window such as for copying paths or other things. This can also be useful for extensions such as MetaMask to allow copying addresses, and I'm sure many other use cases. This the behavior in Chromium, and I don't see why a behavior of closing on clicking out of the window should be expected. If there is a use case for closing the popup on clicking out of the window it shouldn't change, but for now I don't see shouldn't it does.

No, I disagree with you.
The context menu covers other applications and obstruct to use them. The context menu covers other applications and obstruct to use them. It is too annoying for me.

On Google Chrome 115, 116DEV and Chromium 117, the context menu will close automatically when switch to other application.

1. Open app menu(three dots menu)
2. Click on Bookmarks
3. Right mouse click on a bookmark entry
4. Click on the other application button on Windows Taskbar
   or
   Click on Bottom right Show Desktop button of Windows Taskbar

Comment 4

[Alice0775 White]

Attachment: screencast.mp4

The issue is not only the context menu of hamburger menu but also any context menu such as content area and bookmarks on menubar.

Comment 5

[Alice0775 White]

Attachment: screencast.mp4 : context menu stays on top of screen forever...

Comment 6

[Alice0775 White]

Attachment: screencast.mp4 : ordinary menu also stays on top of other application

Comment 7

[Alice0775 White]

[Tracking Requested - why for this release]: Firefox's menu popup obstructs to use the other applications.
Please back out the offending patches.

Comment 8

[Aidan Welch]

It is unexpected behavior that popups/context menus stay open when minimized- but I'm not able to replicate that behavior. The context menu stays over other windows, but the annoying element of that behavior is that context menus are forced to the top- not that they stay open when in other windows. I would argue that should be changed rather than blocking this change allowing for much easier use of certain extensions.

Comment 9

[Alice0775 White]

If there is a desire not to roll up the web-extension's panel, shouldn't the web-extension API be modified/added first?
Then, the author of the web-extension can choose whether or not to roll-up the panel, which would be more convenient for the web-extension author. This way, there should be no negative impact on other Firefox' UIs and other web-extensions.

I think we should reconsider how to implement bug 1292701.

Comment 10

[Ryan VanderMeulen [:RyanVM]]

Chris, as the patch reviewer, can you please weigh in here too?

Comment 11

[BugBot [:suhaib / :marco]]

The bug is marked as tracked for firefox117 (nightly). We have limited time to fix this, the soft freeze is in 3 days. However, the bug still isn't assigned.

:pluk, could you please find an assignee for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 12

[:Gijs (back August 25; he/him)]

The code changes here were in the Windows widget code and any fix would need to live there too, so moving the bug.

Comment 13

[Ray Kraesig [:rkraesig]]

I can reproduce relatively easily. (It does seem to require that Firefox not be maximized, though.)

I also agree that this is a severe enough regression to warrant reverting before the freeze. Self-assigning — although if a release sheriff wants to back it out before the revert patch makes it through Phabricator, that works too.

Comment 14

[Ray Kraesig [:rkraesig]]

Attachment: Bug 1844733 - Revert "Bug 1292701, 1366330 - Fix popup hiding while navigating file picker" r?cmartin

Reverts D172884, aka commit 0c47c1159e0a060ee709f9f8f854bfad27f86c85.

Comment 15

[Alice0775 White]

Attachment: screenshot, Select dropdown also stay, is not hidding.

Select drop-down has also stayed, is not hiding. This is also the same regression range.

STR:

1. Open about:preferences#privacy.
2. Go History section. Click select box of Nightly will
3. Switch to other applications or show desktop

Actual results:
See attached screenshot

Expected results:
The dropdown should disappear.

Comment 16

[Chris Martin [:cmartin]]

Agreed with :rkraesig -- Let's just back it out to be safe. I can't think of a low-risk way to fix this off the top of my head, and we're getting close to soft freeze.

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c30662ce80ba
Revert "Bug 1292701, 1366330 - Fix popup hiding while navigating file picker"  r=cmartin

Comment 18

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/c30662ce80ba

Comment 19

[Monica Chiorean (OOO August 21st 5:30PM)]

I was able to reproduce the issue on Win10x64 using FF build 117.0a1(20230713214846).
Verified as fixed on Win10x64 / Ubuntu 20.04 using FF build 117.0b3(20230803180221).