1763990 - Context menus flashing and popping behind bookmarks menu

Status: VERIFIED FIXED

(Core :: Widget: Cocoa, defect, P3)

Description

[MarjaE]

Steps to reproduce:

Opened a folder in my bookmarks toolbar.

Moused over a bookmark.

Right-clicked.

Actual results:

Instead of staying open so I could use the contextual menu, if flashed open and closed in an instant.

Expected results:

It should have stayed open.

Regressed by bug 1746310.

https://phabricator.services.mozilla.com/D134606

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1746310

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

:emilio, since you are the author of the regressor, bug 1746310, could you take a look?
For more information, please visit auto_nag documentation.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

This is in the library window? I can't repro this on Linux, which OS are you on?

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Err, sorry, bookmarks toolbar. I still can't repro on Linux (Wayland) for that matter. Will try on X11 and on Windows later today.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Can't repro this on Windows either, is there something on your setup that can cause this? userChrome.css perhaps?

Comment 7

[MarjaE]

MacOS.

I still run into the bug in Troubleshoot Mode. I tried Mozregression without a profile, but, of course, didn't have enough bookmarks there to test this.

Comment 8

[MarjaE]

Attachment: Screen Recording 2022-04-11 at 10.06.09 AM.mov

Attached screenshot. It looks like the contextual menu pops up in front of the bookmarks menu and then jumps behind it.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Can't repro on macOS as well, maybe export the bookmarks and import them into a clean profile?

Comment 10

[MarjaE]

Attachment: Screen Shot 2022-04-11 at 10.43.31 AM.png

It still occurs in a new profile, see 10.43.31.

Comment 11

[MarjaE]

Okay, it still occurs:

Comment 12

[Emilio Cobos Álvarez (:emilio)]

Gijs, can you repro by any chance? I can't so it's hard to know what might be going on...

Comment 13

[:Gijs (he/him)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #12)

Gijs, can you repro by any chance? I can't so it's hard to know what might be going on...

No, I cannot. The context menu stays open for me, on macOS 11.6 (Big Sur).

Marja, what version of macOS is this? Are there any OS-level customizations you've made that might be related?

Comment 14

[MarjaE]

I'm using 10.14.6. Can't think what could affect this.

It doesn't show up in console.

Comment 15

[MarjaE]

Appears to be a duplicate of bug 1755228.

Comment 17

[:Gijs (he/him)]

Let's keep the discussion here as there's more detailed information here than in the older bug.

Markus or Stephen, do either of you have access to a macOS 10.14 machine on which you can reproduce?

Comment 18

[Stephen A Pohl [:spohl]]

(In reply to :Gijs (he/him) from comment #17)

Let's keep the discussion here as there's more detailed information here than in the older bug.

Markus or Stephen, do either of you have access to a macOS 10.14 machine on which you can reproduce?

I have a macOS 10.14.6 system and tried to reproduce this with a fresh install of Firefox Release 99 and a clean profile. I'm unable to reproduce this bug. Here is what I tried:

1. Set bookmarks toolbar to show permanently.
2. Create folder in bookmarks toolbar.
3. Create one bookmark inside the folder.
4. Right click on the bookmark inside the folder.

Am I missing something? Does this require a certain number of bookmarks in the folder? Does it require an external mouse?

Comment 19

[MarjaE]

I don't know. It can occur in a folder with only 2 bookmarks.

Comment 20

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:spohl, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 22

[:Gijs (he/him)]

Markus, is there some way affected users could get us more information with MOZ_LOG or similar, that'd help figure out why we can't repro but different users can?

Comment 23

[BugBot [:suhaib / :marco/ :calixte]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 24

[Emilio Cobos Álvarez (:emilio)]

I suspect bug 1771262 could explain this.

Comment 25

[Ryan VanderMeulen [:RyanVM]]

Is this any better on Nightly or Beta with bug 1771262 fixed?

Comment 26

[MarjaE]

It's still buggy as of here: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=99b0e3dc143efcb478c2252865b0e09371f4a99e&tochange=d9bf7a44ab1c54125f36a7335b5a028cc89c8025

That's the most recent I was able to test using Mozregression.

Comment 27

[William Durand [:willdurand]]

Attachment: Screenshot 2022-07-25 at 11.39.16.png

I confirm this is still happening on MacOS. I am working on a new panel that has context menu defined on a button. When I open the context menu, it is displayed on top of the panel for a second, then goes behind the panel (or rather the panel goes above the context menu). Sub-menus are displayed on top of the panel, though.

In the screenshot, I opened the context menu defined on the button next to "Tree Style Tab".

The pref widget.macos.native-context-menus set to false as mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1755228#c2 seems to make this problem go away.

Comment 29

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates.
:spohl, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 30

[Markus Stange [:mstange]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #24)

I suspect bug 1771262 could explain this.

nsCocoaWindow does not implement SetZIndex, so this bug is probably unrelated to the z-index.

I suspect something is calling orderFront or makeKeyAndOrderFront on the popup window while the context menu is visible. It looks like the only relevant callers are nsCocoaWindow::Focus and nsCocoaWindow::Show. I'll make a try build where those two methods add profiler markers with stacks, then we might be able to debug this with the profiler.

Comment 31

[Markus Stange [:mstange]]

https://treeherder.mozilla.org/jobs?repo=try&revision=6b7c5d778d483bc3c37b68f0c22fe8a9858c09d0

Comment 32

[Ryan VanderMeulen [:RyanVM]]

Will, can you try the build from comment 31 and see if we get useful info from the profiler when it happens?

Comment 33

[William Durand [:willdurand]]

Sorry for the delay, I applied the patch from comment 31 locally. Would this profile be useful? https://profiler.firefox.com/from-browser/marker-chart/?globalTrackOrder=0w7&hiddenGlobalTracks=1w6&hiddenLocalTracksByPid=764-0wh~775-0~3190-0~3218-0~3217-0~779-0~3191-0&localTrackOrderByPid=764-ij0e1hfg52w46w8ca9db&thread=0&v=7

Comment 34

[Donal Meehan [:dmeehan]]

Looks like it's too late for 107.
Leaving 108 status clear, unless anyone thinks we should be following this for a fix in 108?
There is a pending needinfo from comment 33

Comment 35

[:Gijs (he/him)]

(In reply to William Durand [:willdurand] from comment #33)

Sorry for the delay, I applied the patch from comment 31 locally. Would this profile be useful? https://profiler.firefox.com/from-browser/marker-chart/?globalTrackOrder=0w7&hiddenGlobalTracks=1w6&hiddenLocalTracksByPid=764-0wh~775-0~3190-0~3218-0~3217-0~779-0~3191-0&localTrackOrderByPid=764-ij0e1hfg52w46w8ca9db&thread=0&v=7

I believe this isn't a shareable profile link - if you profile locally you need to use the share button to share it and get a shortlink, just copying the URL is not enough (the "from-browser" bit I think means profile data has to come from the local browser, which of course isn't possible for other folks)>

Comment 36

[William Durand [:willdurand]]

hmf, sorry. Didn't find any obvious sharing feature so I thought it was automatic.. Here is a new profile that I hope people other than me can open: https://share.firefox.dev/3DfpXV1

Comment 37

[:Gijs (he/him)]

(In reply to William Durand [:willdurand] from comment #36)

hmf, sorry. Didn't find any obvious sharing feature so I thought it was automatic.. Here is a new profile that I hope people other than me can open: https://share.firefox.dev/3DfpXV1

This has one CocoaWindowShow marker in the parent process, with this stack:

(root) []
start [dyld]
main [mozilla-central/browser/app/nsBrowserApp.cpp]
do_main(int, char**, char**) [mozilla-central/browser/app/nsBrowserApp.cpp]
XRE_main(int, char**, mozilla::BootstrapConfig const&) [mozilla-central/toolkit/xre/nsAppRunner.cpp]
XREMain::XRE_main []
XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) [mozilla-central/toolkit/xre/nsAppRunner.cpp]
XREMain::XRE_mainRun() [mozilla-central/toolkit/xre/nsAppRunner.cpp]
nsAppStartup::Run() [mozilla-central/toolkit/components/startup/nsAppStartup.cpp]
nsAppShell::Run() [mozilla-central/widget/cocoa/nsAppShell.mm]
-[NSApplication run] [AppKit]
-[GeckoNSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] [mozilla-central/widget/cocoa/nsAppShell.mm]
-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] [AppKit]
_DPSNextEvent [AppKit]
_BlockUntilNextEventMatchingListInModeWithFilter [HIToolbox]
ReceiveNextEventCommon [HIToolbox]
RunCurrentEventLoopInMode [HIToolbox]
CFRunLoopRunSpecific [CoreFoundation]
__CFRunLoopRun [CoreFoundation]
__CFRunLoopDoSources0 [CoreFoundation]
__CFRunLoopDoSource0 [CoreFoundation]
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ [CoreFoundation]
nsAppShell::ProcessGeckoEvents []
nsAppShell::ProcessGeckoEvents(void*) [mozilla-central/widget/cocoa/nsAppShell.mm]
nsBaseAppShell::NativeEventCallback() [mozilla-central/widget/nsBaseAppShell.cpp]
NS_ProcessPendingEvents(nsIThread*, unsigned int) [mozilla-central/xpcom/threads/nsThreadUtils.cpp]
nsThread::ProcessNextEvent(bool, bool*) [mozilla-central/xpcom/threads/nsThread.cpp]
mozilla::detail::RunnableFunction<mozilla::TaskController::InitializeInternal()::$_3>::Run() [mozilla-central/objdir-frontend-debug-artifact/dist/include/nsThreadUtils.h]
mozilla::TaskController::InitializeInternal()::$_3::operator()() const [mozilla-central/xpcom/threads/TaskController.cpp]
mozilla::TaskController::ProcessPendingMTTask(bool) [mozilla-central/xpcom/threads/TaskController.cpp]
mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) [mozilla-central/xpcom/threads/TaskController.cpp]
Task nsRefreshDriver::FinishedWaitingForTransaction(unlabeled) []
mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) [mozilla-central/xpcom/threads/TaskController.cpp]
mozilla::RunnableTask::Run() [mozilla-central/xpcom/threads/TaskController.cpp]
mozilla::detail::RunnableFunction<nsRefreshDriver::FinishedWaitingForTransaction()::$_6>::Run() [mozilla-central/objdir-frontend-debug-artifact/dist/include/nsThreadUtils.h]
nsRefreshDriver::FinishedWaitingForTransaction()::$_6::operator()() const [mozilla-central/layout/base/nsRefreshDriver.cpp]
RefreshDriver tick []
nsRefreshDriver::Tick(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp, nsRefreshDriver::IsExtraTick) [mozilla-central/layout/base/nsRefreshDriver.cpp]
nsViewManager::ProcessPendingUpdates() [mozilla-central/view/nsViewManager.cpp]
nsViewManager::ProcessPendingUpdatesForView(nsView*, bool) [mozilla-central/view/nsViewManager.cpp]
nsView::ResetWidgetBounds(bool, bool) [mozilla-central/view/nsView.cpp]
nsView::DoResetWidgetBounds(bool, bool) [mozilla-central/view/nsView.cpp]
nsCocoaWindow::Show(bool) [mozilla-central/widget/cocoa/nsCocoaWindow.mm]
profiler_add_marker(mozilla::ProfilerStringView<char> const&, mozilla::MarkerCategory const&, mozilla::MarkerOptions&&) [mozilla-central/objdir-frontend-debug-artifact/dist/include/mozilla/ProfilerMarkers.h]

I'm hoping this is helpful for Markus... :-)

Comment 40

[:Gijs (he/him)]

Honestly considering the number of dupes I think we should reconsider the priority here...

Comment 42

[Stephen A Pohl [:spohl]]

Bug 1800742 is an interesting bug on Windows and could indicate an issue with the popup dialog itself (somehow, ordering itself much higher in the z order than it should), rather than the context menu here.

Comment 43

[Stephen A Pohl [:spohl]]

... and bug 1800742 claims that the issue there is a regression from bug 1766197.

Comment 44

[MarjaE]

To test in Mozregression without your profile:

1. Run Mozregression.

2. When it opens a new version, create a bookmarks folder in your bookmarks toolbar, and move "Get Involved" into that folder.

Comment 45

[MarjaE]

Attachment: Screen Recording 2022-12-19 at 4.36.19 PM.mov

Example: testing 2022-01-22 without my usual profile.

Comment 46

[MarjaE]

I've tried retrying each seeming success 3 times, so inconsistent results won't throw things off.

Using the above test method instead of using my usual profile, I consistently get the context menu in front of the bookmark folder before https://phabricator.services.mozilla.com/D134606 and behind the bookmark folder afterwards.

In turn, that points to https://bugzilla.mozilla.org/show_bug.cgi?id=1746310

I think that confirms my original regression test, instead of the alternative one.

Comment 48

[tim]

Not sure if this is helpful at all (and hopefully it's related to this bug), but I've noticed that the context menu displays below the bookmarks menu on macOS 13.1 (22C65) and Firefox 108.0.2 (64-bit):

• Only when Firefox is in full screen
• Only when widget.macos.native-context-menus is set to true

This bug has made me realize how often I right-click on bookmarks to do stuff. 😅 Fortunately, setting widget.macos.native-context-menus to false seems to be a workaround.

Comment 51

[Markus Stange [:mstange]]

(In reply to tim from comment #48)

• Only when Firefox is in full screen

I can reproduce it in full screen mode! But I'm not sure if fixing this would fix the original bug.

But maybe I can write a workaround without being able to reproduce this bug. For example, maybe there's a way to prevent all window re-ordering calls while a context menu is open.

Comment 54

[:Gijs (he/him)]

(In reply to Markus Stange [:mstange] from comment #51)

(In reply to tim from comment #48)

• Only when Firefox is in full screen

I can reproduce it in full screen mode! But I'm not sure if fixing this would fix the original bug.

But maybe I can write a workaround without being able to reproduce this bug. For example, maybe there's a way to prevent all window re-ordering calls while a context menu is open.

That'd be great! I figured it's worth noting this is one of only 2 user-facing bugs filed in the last year with more than 10 dupes. Markus, is investigating and fixing this something you can take on, and if not, who could suggest someone else?

Comment 55

[Stephen A Pohl [:spohl]]

(In reply to :Gijs (he/him) from comment #54)

That'd be great! I figured it's worth noting this is one of only 2 user-facing bugs filed in the last year with more than 10 dupes. Markus, is investigating and fixing this something you can take on, and if not, who could suggest someone else?

We discussed this bug in our team yesterday. There are some other important bugs that we're working on, but this one is next on the list. Markus or I will be looking into it.

Comment 56

[Stephen A Pohl [:spohl]]

I have spent a considerable amount of time today trying to reproduce this issue across a variety of different MacBooks and macOS versions, fullscreen and non-fullscreen, but I have yet to reproduce. I'll see what I can do without reproducing.

Comment 57

[Stephen A Pohl [:spohl]]

I created a local build that reproduces an issue that looks identical to the one reported here and I'm looking into it. Once I have a patch I'll ask for someone here to confirm that this also addresses the reported issue in this bug.

Comment 58

[Stephen A Pohl [:spohl]]

Here is a build with a possible fix. You may have to launch it manually from system settings (or right-click > open) since it's a try build without the proper codesign signature.

https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/MLvdm6XxQM6coEEzrryMxg/runs/0/artifacts/public/build/target.dmg

Could you let me know if this fixes the issue? Could you also verify that the popup and the bookmark tooltip behave as expected, i.e. the bookmark folder popup shouldn't disappear while the context menu is open etc. Thanks!

Comment 59

[tim]

Attachment: Screenshot 2023-01-31 at 11.49.31 AM.png

Unfortunately, the issue persists. I added some bookmarks to a folder, switched to full-screen mode, and right-clicked on a bookmark from the folder. The bookmark menu stayed open, but the context menu still appeared behind it.

Comment 60

[Stephen A Pohl [:spohl]]

This wasn't what I was hoping to hear, but I may just have been able to reproduce the issue in fullscreen!

1. Could you please confirm if you have any external monitors? If so, how many?
2. What is your setting for "Displays have separate Spaces" in System Settings > Desktop & Dock?
3. Are you able to reproduce the issue if you disconnect the external monitors (if any)?
4. Are you able to reproduce the issue if you switch the setting for "Displays have separate Spaces" in System Settings > Desktop & Dock?

Comment 61

[MarjaE]

The test version works for me.

Comment 62

[Stephen A Pohl [:spohl]]

(In reply to MarjaE from comment #61)

The test version works for me.

This is in non-fullscreen, correct? Would you be able to answer my questions in comment 60 as well? This could help me find a universal fix for both fullscreen and non-fullscreen. Thank you!

Comment 63

[tim]

(In reply to Stephen A Pohl [:spohl] from comment #60)

This wasn't what I was hoping to hear, but I may just have been able to reproduce the issue in fullscreen!

1. Could you please confirm if you have any external monitors? If so, how many?
2. What is your setting for "Displays have separate Spaces" in System Settings > Desktop & Dock?
3. Are you able to reproduce the issue if you disconnect the external monitors (if any)?
4. Are you able to reproduce the issue if you switch the setting for "Displays have separate Spaces" in System Settings > Desktop & Dock?

1. When I used the test build you provided, I was using just the built-in display on my MacBook.
2. Displays Have Separate Spaces = Enabled
3. n/a
4. When I disable "Displays Have Separate Spaces", the bug no longer occurs

Comment 64

[MarjaE]

I can't test fullscreen without migraines. As for these questions...

1. This computer only has an external monitor.

2. It's under Mission Control here, and I had not checked that option; I hate Spaces.

3. I can't test without any monitor.

4. If I add another monitor, and check that option, and manage to move the Firefox Nightly Window to that other monitor, I can't move my mouse over there to test this. I get an awful migraine from the default smooth/painful animations in Firefox, System Preferences, etc. as I try to work through this.

Comment 65

[Stephen A Pohl [:spohl]]

Please do not test anything that would cause migraines. That was not my intention. Thank you both for all the help and additional info. This should be sufficient to make progress on this bug.

Comment 66

[mindovermiles262]

Could you please confirm if you have any external monitors? If so, how many?

One external monitor, though I work in clamshell mode most days (laptop closed, external monitor attached and running as primary screen)

What is your setting for "Displays have separate Spaces" in System Settings > Desktop & Dock?

"Displays have seprate Spaces" is enabled

Are you able to reproduce the issue if you disconnect the external monitors (if any)?

Yes, issue persists when external monitor is disconnected

Are you able to reproduce the issue if you switch the setting for "Displays have separate Spaces" in System Settings > Desktop & Dock?

Unable to reproduce the issue when "Displays have separate Spaces" is disabled.

Comment 67

[Stephen A Pohl [:spohl]]

I may have found a universal fix for this for both fullscreen and non-fullscreen, but I would need to get confirmation first. Would you be able to test this build in your usual configuration, and in any additional configurations that you feel comfortable testing? For example:

1. with & without external monitors
2. "Displays have separate spaces" enabled and disabled
3. fullscreen and non-fullscreen

Thank you!

Comment 68

[mindovermiles262]

I can confirm that the issue is fixed with and with out an external monitor, with and without "Dispays have separate spaces" enabled, with and without fullscreen (and all combinations). Looks like this issue is fixed with your patches. Thank you!

Comment 69

[tim]

(In reply to Stephen A Pohl [:spohl] from comment #67)

I may have found a universal fix for this for both fullscreen and non-fullscreen, but I would need to get confirmation first. Would you be able to test this build in your usual configuration, and in any additional configurations that you feel comfortable testing? For example:

1. with & without external monitors
2. "Displays have separate spaces" enabled and disabled
3. fullscreen and non-fullscreen

Thank you!

1. Only tested with my built-in macbook display
2. Tested with both settings
3. Tested with with fullscreen and windowed

In all three tests, the bug no longer appeared. Seems to be fixed in this build!

Comment 70

[Stephen A Pohl [:spohl]]

Attachment: Bug 1763990: Don't order popups in front of native context menus on macOS. r=mstange

Comment 71

[Stephen A Pohl [:spohl]]

This is great! Thank you all for testing the build so quickly.

Comment 72

[MarjaE]

Working with 1 monitor in 10.14.6.

Comment 73

[Stephen A Pohl [:spohl]]

The implementation of the fix here has slightly changed from the previous build, but as far as I can tell we continue to display the context menu correctly. If you feel inclined to test the latest version, here is a new build with the latest implementation. I don't expect any surprises, but it never hurts to have independent confirmation.

Comment 74

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a49a06435197
Don't order popups in front of native context menus on macOS. r=mstange

Comment 75

[tim]

(In reply to Stephen A Pohl [:spohl] from comment #73)

The implementation of the fix here has slightly changed from the previous build, but as far as I can tell we continue to display the context menu correctly. If you feel inclined to test the latest version, here is a new build with the latest implementation. I don't expect any surprises, but it never hurts to have independent confirmation.

I tested with the same combinations of settings and displays as https://bugzilla.mozilla.org/show_bug.cgi?id=1763990#c69 and it still works like a charm.

Comment 76

[Iulian Moraru]

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

Comment 79

[Stephen A Pohl [:spohl]]

Comment on attachment 9315508 [details]
Bug 1763990: Don't order popups in front of native context menus on macOS. r=mstange

Beta/Release Uplift Approval Request

• User impact if declined: Context menus can appear behind popups such as opening a folder in the bookmarks toolbar. Considering the number of duplicate bugs it is fair to assume that a significant number of users are running into this issue.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: 1. Set bookmarks toolbar to always show under View > Toolbars > Bookmarks Toolbar

2. Create a folder with at least one bookmark in the Bookmarks Toolbar
3. Right click on the bookmark in the folder.
4. Verify that the context menu appears on top of the folder popup.

Repeat steps 3 and 4 in the following configurations:

1. Fullscreen and non-fullscreen (windowed) mode.
2. On internal screen (for example MacBook) and external screen.
3. With "Displays have separate Spaces" turned on and off in macOS System Settings > Desktop & Dock.

• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This is a very narrow and well understood change. We made sure to keep the patch isolated to macOS, even though Gtk might benefit from a similar patch in the future.
• String changes made/needed: none
• Is Android affected?: Yes

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Given that this is a very narrow change that appears to impact a significant number of users, it seems reasonable to address this issue in ESR.
• User impact if declined: Context menus can appear behind popups such as opening a folder in the bookmarks toolbar. Considering the number of duplicate bugs it is fair to assume that a significant number of users are running into this issue.
• Fix Landed on Version: 111
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This is a very narrow and well understood change. We made sure to keep the patch isolated to macOS, even though Gtk might benefit from a similar patch in the future.

Comment 80

[Stephen A Pohl [:spohl]]

I'm going to remove bug 1746310 as regressor because it merely exposed an existing issue that needed to be addressed independently.

Comment 82

[Pascal Chevrel:pascalc]

Comment on attachment 9315508 [details]
Bug 1763990: Don't order popups in front of native context menus on macOS. r=mstange

We have shipped this bug for many releases and we are building our RC today, the risk/benefit ratio seems too high to uplift just before shipping. I am morphing this into a mozilla-release uplift request, let's reevaluate in a couple of weeks if we take it in our planned dot release or just let it ride the 111 train.

Comment 83

[Donal Meehan [:dmeehan]]

Putting on the radar for potential uplift for esr102.9

Comment 84

[Ina Popescu, Desktop QA]

Reproduced the issue on Nightly 101.0a1(2022-04-10) on macOS 13.2 by following the STR from Comment 79 and the ones from the duplicates.

This was reproduced in the following configurations:

1. Fullscreen mode on.
2. On internal screen screen(MacBook Air).
3. With "Displays have separate Spaces" turned on and off in macOS System Settings > Desktop & Dock

The issue is no longer reproducible on Nightly 111.0a1 (2023-02-07) on the same system using same configuration as above.

Comment 87

[Pascal Chevrel:pascalc]

Comment on attachment 9315508 [details]
Bug 1763990: Don't order popups in front of native context menus on macOS. r=mstange

Although this is a long-standing issues, we have 16 duplicates and most of them filed recently (2 with Firefox 110), this was verified on nightly and beta and it baked a couple of weeks with no regression reported. Let's take it in our planned dot release 110.0.1, thanks.

Comment 88

[Pascal Chevrel:pascalc]

https://hg.mozilla.org/releases/mozilla-release/rev/01229c45df3d

Comment 90

[Donal Meehan [:dmeehan]]

Comment on attachment 9315508 [details]
Bug 1763990: Don't order popups in front of native context menus on macOS. r=mstange

Approved for 102.9esr.

Comment 91

[Donal Meehan [:dmeehan]]

https://hg.mozilla.org/releases/mozilla-esr102/rev/66a561c05346

Comment 92

[Ina Popescu, Desktop QA]

Reproduced the issue on Firefox 110.0 on macOS Ventura 13.2(b),M1 by following the STR from Comment 79( + the ones from the duplicates) and in the following configuration:

1. Fullscreen mode on.
2. On internal screen screen(MacBook Air).
3. With "Displays have separate Spaces" turned on in macOS System Settings > Desktop & Dock

The issue is no longer reproducible on Firefox 110.0.1 on the same system in same configuration as above.

Please note that I wasn't able to reproduce the issue in non-fullscreen (windowed) mode.

Comment 93

[Ina Popescu, Desktop QA]

Reproduced the issue on Firefox 102.8.0esr-candidates/build2 on macOS Ventura 13.2(b),M1 by following the STR from Comment 79 in the following configuration:

• Fullscreen mode on.
• On internal screen screen(MacBook Air).
• With "Displays have separate Spaces" turned on in macOS System Settings > Desktop & Dock

The issue is no longer reproducible on Firefox 102.9.0esr-candidates/build1 on the same system in same configuration as above.
Please note that I wasn't able to reproduce the issue in non-fullscreen (windowed) mode.