Closed Bug 1763990 Opened 2 years ago Closed 1 year ago

Context menus flashing and popping behind bookmarks menu

Categories

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

Firefox 99
defect

Tracking

()

VERIFIED FIXED
111 Branch
Tracking Status
firefox-esr91 --- unaffected
firefox-esr102 111+ verified
firefox99 --- wontfix
firefox100 --- wontfix
firefox101 --- wontfix
firefox102 --- wontfix
firefox103 --- wontfix
firefox104 --- wontfix
firefox105 --- wontfix
firefox106 --- wontfix
firefox107 --- wontfix
firefox109 --- wontfix
firefox110 --- verified
firefox111 --- verified

People

(Reporter: erwinm, Assigned: spohl)

References

Details

(Keywords: regression)

Attachments

(6 files)

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

Regressed by: 1746310

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.

Component: Untriaged → Widget: Cocoa
Product: Firefox → Core

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

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

Flags: needinfo?(emilio)

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

Flags: needinfo?(emilio) → needinfo?(erwinm)

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

Has Regression Range: --- → yes

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

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.

Flags: needinfo?(erwinm)

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

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

Flags: needinfo?(erwinm)

It still occurs in a new profile, see 10.43.31.

Flags: needinfo?(erwinm)

Okay, it still occurs:

Summary: Context menus flashing instead of staying open → Context menus flashing and popping behind bookmarks menu

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

Flags: needinfo?(gijskruitbosch+bugs)

(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?

Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(erwinm)

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

It doesn't show up in console.

Flags: needinfo?(erwinm)

Appears to be a duplicate of bug 1755228.

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?

Flags: needinfo?(spohl.mozilla.bugs)
Flags: needinfo?(mstange.moz)

(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?

Flags: needinfo?(spohl.mozilla.bugs)
Flags: needinfo?(mstange.moz)
Flags: needinfo?(erwinm)

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

Flags: needinfo?(erwinm)

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(spohl.mozilla.bugs)

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?

Flags: needinfo?(mstange.moz)
Severity: -- → S3
Flags: needinfo?(spohl.mozilla.bugs)
Priority: -- → P3

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

Status: UNCONFIRMED → NEW
Ever confirmed: true
See Also: → 1771262

I suspect bug 1771262 could explain this.

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

Flags: needinfo?(erwinm)
Flags: needinfo?(erwinm)

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.

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.

Flags: needinfo?(spohl.mozilla.bugs)
Flags: needinfo?(spohl.mozilla.bugs)

(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.

Flags: needinfo?(mstange.moz)

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

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

(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)>

Flags: needinfo?(wdurand)

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

Flags: needinfo?(wdurand)

(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... :-)

Duplicate of this bug: 1801070
Duplicate of this bug: 1803844

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

Severity: S3 → --
Duplicate of this bug: 1805980
Severity: -- → S2

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.

See Also: → 1800742

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

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.

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

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.

See Also: → 1806992
Duplicate of this bug: 1808547

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.

Duplicate of this bug: 1810273
Duplicate of this bug: 1810416

(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.

Flags: needinfo?(mstange.moz)
Duplicate of this bug: 1810637
Duplicate of this bug: 1811102

(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?

Flags: needinfo?(mstange.moz)

(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.

Flags: needinfo?(mstange.moz)

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.

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.

Assignee: nobody → spohl.mozilla.bugs
Status: NEW → ASSIGNED

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!

Flags: needinfo?(wdurand)
Flags: needinfo?(tim)
Flags: needinfo?(erwinm)

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.

Flags: needinfo?(tim)

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?
Flags: needinfo?(tim)

The test version works for me.

Flags: needinfo?(erwinm)

(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!

Flags: needinfo?(erwinm)

(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
Flags: needinfo?(tim)

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.

Flags: needinfo?(erwinm)

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.

Flags: needinfo?(wdurand)

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.

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!

Flags: needinfo?(tim)
Flags: needinfo?(mindovermiles262)
Flags: needinfo?(erwinm)

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!

Flags: needinfo?(mindovermiles262)

(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!

Flags: needinfo?(tim)

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

Working with 1 monitor in 10.14.6.

Flags: needinfo?(erwinm)

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.

Pushed by spohl@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a49a06435197
Don't order popups in front of native context menus on macOS. r=mstange

(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.

Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 111 Branch
Duplicate of this bug: 1767009
Duplicate of this bug: 1814925

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
  1. Create a folder with at least one bookmark in the Bookmarks Toolbar
  2. Right click on the bookmark in the folder.
  3. 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.
Attachment #9315508 - Flags: approval-mozilla-esr102?
Attachment #9315508 - Flags: approval-mozilla-beta?
Flags: qe-verify+

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

No longer regressed by: 1746310
See Also: → 1815125
Duplicate of this bug: 1815125
QA Whiteboard: [qa-triaged]

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.

Attachment #9315508 - Flags: approval-mozilla-release?
Attachment #9315508 - Flags: approval-mozilla-beta?
Attachment #9315508 - Flags: approval-mozilla-beta-

Putting on the radar for potential uplift for esr102.9

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.

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
Flags: qe-verify+
Duplicate of this bug: 1816106
Duplicate of this bug: 1818138

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.

Attachment #9315508 - Flags: approval-mozilla-release? → approval-mozilla-release+
Duplicate of this bug: 1818951

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.

Attachment #9315508 - Flags: approval-mozilla-esr102? → approval-mozilla-esr102+

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.

Regressions: 1819644
No longer regressions: 1819644

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.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: