Affected versions

• Firefox 89.0a1 (BuildId:20210405212812)

Affected platforms

• macOS 11
• macOS 10.15.7

Unaffected platforms

• Windows 10 64bit.
• Ubuntu 20.04

Preconditions

• Have the widget.macos.native-context-menus and the browser.proton.enabled prefs enabled.

Steps to reproduce

1. Launch Firefox.
2. Access the following link
3. Open any random video.
4. Double right click on the video in order to open the Firefox context menu.
5. Wait until the video’s seekbar gets hidden (while the context menu is open).
6. Once the seekbar gets hidden, navigate using your trackpad on the context menu options.

Expected result

• The cursor reappears successfully while trying to navigate through the Firefox context menu options.

Actual result

• The cursor stays hidden.

Regression Range

• I'll search for a regression asap.

Notes

• For a screencast regarding this issue, please access the following link (Mozilla account needed).
• Please note that this issue is not reproducible while the widget.macos.native-context-menus is set to false.

Emil, do you have a regression window for this issue please?

Romain, sorry for the long delay on this.

It seems that this is not a regression for the macOS native context menu. This issue is reproducible with builds from 2021-03-23 as well ( When the initial support for native context menus landed in Bug 1698997).

As a note from the regression search: On builds from 2021-03-23 the browser.proton.contextmenus.enabled pref had to be manually enabled as well (alongside with widget.macos.native-context-menus) because they are builds pre Bug 1702387.

Markus, I think this is a widget issue, and I think I have a rough understanding of what causes it, but not sure how to help fix it. AFAICT, with non-native menus, as soon as the mouse moves after it's been hidden, we get this stack:

01: -[nsCursorManager setCursor:][$OBJDIR/toolkit/library/build/XUL +0x2bfd83a]
#02: nsChildView::SetCursor(nsCursor, imgIContainer*, unsigned int, unsigned int)[$OBJDIR/toolkit/library/build/XUL +0x2ba5c6e]
#03: mozilla::EventStateManager::SetCursor(mozilla::StyleCursorKind, imgIContainer*, mozilla::Maybe<mozilla::gfx::IntPointTyped<mozilla::gfx::UnknownUnits> > const&, nsIWidget*, bool)[$OBJDIR/toolkit/library/build/XUL +0x1fb222a]
#04: mozilla::EventStateManager::UpdateCursor(nsPresContext*, mozilla::WidgetEvent*, nsIFrame*, nsEventStatus*)[$OBJDIR/toolkit/library/build/XUL +0x1fa8f5a]
#05: mozilla::EventStateManager::PreHandleEvent(nsPresContext*, mozilla::WidgetEvent*, nsIFrame*, nsIContent*, nsEventStatus*, nsIContent*)[$OBJDIR/toolkit/library/build/XUL +0x1fa6353]
#06: mozilla::PresShell::EventHandler::DispatchEvent(mozilla::EventStateManager*, mozilla::WidgetEvent*, bool, nsEventStatus*, nsIContent*)[$OBJDIR/toolkit/library/build/XUL +0x2dbe5f9]
#07: mozilla::PresShell::EventHandler::HandleEventWithCurrentEventInfo(mozilla::WidgetEvent*, nsEventStatus*, bool, nsIContent*)[$OBJDIR/toolkit/library/build/XUL +0x2dbbf5c]
#08: mozilla::PresShell::EventHandler::HandleEventWithTarget(mozilla::WidgetEvent*, nsIFrame*, nsIContent*, nsEventStatus*, bool, nsIContent**, nsIContent*)[$OBJDIR/toolkit/library/build/XUL +0x2dbd99a]
#09: mozilla::PointerEventHandler::DispatchPointerFromMouseOrTouch(mozilla::PresShell*, nsIFrame*, nsIContent*, mozilla::WidgetGUIEvent*, bool, nsEventStatus*, nsIContent**)[$OBJDIR/toolkit/library/build/XUL +0x200b4aa]
#10: mozilla::PresShell::EventHandler::DispatchPrecedingPointerEvent(nsIFrame*, mozilla::WidgetGUIEvent*, nsIContent*, bool, mozilla::PresShell::EventHandler::EventTargetData*, nsEventStatus*)[$OBJDIR/toolkit/library/build/XUL +0x2dbcdd0]
#11: mozilla::PresShell::EventHandler::HandleEventUsingCoordinates(nsIFrame*, mozilla::WidgetGUIEvent*, nsEventStatus*, bool)[$OBJDIR/toolkit/library/build/XUL +0x2dbba83]
#12: mozilla::PresShell::HandleEvent(nsIFrame*, mozilla::WidgetGUIEvent*, bool, nsEventStatus*)[$OBJDIR/toolkit/library/build/XUL +0x2dba672]
#13: nsViewManager::DispatchEvent(mozilla::WidgetGUIEvent*, nsView*, nsEventStatus*)[$OBJDIR/toolkit/library/build/XUL +0x2b3a45c]
#14: nsView::HandleEvent(mozilla::WidgetGUIEvent*, bool)[$OBJDIR/toolkit/library/build/XUL +0x2b3a2b1]
#15: nsChildView::DispatchEvent(mozilla::WidgetGUIEvent*, nsEventStatus&)[$OBJDIR/toolkit/library/build/XUL +0x2ba8c2c]
#16: nsBaseWidget::ProcessUntransformedAPZEvent(mozilla::WidgetInputEvent*, mozilla::layers::APZEventResult const&)[$OBJDIR/toolkit/library/build/XUL +0x2b43cdd]
#17: nsBaseWidget::DispatchInputEvent(mozilla::WidgetInputEvent*)[$OBJDIR/toolkit/library/build/XUL +0x2b444fc]
#18: -[ChildView handleMouseMoved:][$OBJDIR/toolkit/library/build/XUL +0x2bb2443]
#19: ChildViewMouseTracker::MouseMoved(NSEvent*)[$OBJDIR/toolkit/library/build/XUL +0x2bba533]
#20: -[NSTrackingArea mouseMoved:][/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x31be93]
#21: -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:][/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x1e74a7]
#22: -[NSWindow(NSEventRouting) sendEvent:][/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x1e61c9]
#23: -[ToolbarWindow sendEvent:][$OBJDIR/toolkit/library/build/XUL +0x2bfc10a]
#24: -[NSApplication(NSEvent) sendEvent:][/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x1e50c2]
#25: -[GeckoNSApplication sendEvent:][$OBJDIR/toolkit/library/build/XUL +0x2beabe4]

into nsCursorManager setCursor with a non-none cursor, so we hit https://searchfox.org/mozilla-central/rev/a5bf5d0720f9454687f500513ac82b0c8abce5a4/widget/cocoa/nsCursorManager.mm#229 .

With the native menus, this doesn't happen, but we do hit the "hide" case when the cursor and the seekbar is hidden (while the context menu is open) - I haven't checked exactly where that's coming from though.

I'm guessing either we should ensure that either we don't hide the cursor while the native context menu is up, or we make sure to unhide it even when the native menu is up. I'm not sure how to do either, or what the root cause is for us not getting the mouse events - perhaps we intentionally don't want mouse events over the native menu, perhaps apple isn't giving them to us - but atm we don't even unhide the mouse when the mouse moves over bits of the main app window, which feels odd...

Thanks for debugging this, Gijs!

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

I'm guessing either we should ensure that either we don't hide the cursor while the native context menu is up,

I agree. We hide the mouse because we think it is still over the element with the CSS cursor style. I think we should send a "mouse exit" event when the menu opens, so that Gecko thinks the mouse isn't over anything. Then it won't try to update the cursor.

or what the root cause is for us not getting the mouse events - perhaps we intentionally don't want mouse events over the native menu, perhaps apple isn't giving them to us

macOS isn't giving them to us.

This avoids unintended cursor changes and tooltips while the menu is open.
The menu consumes all mouse move events during that time.

https://hg.mozilla.org/mozilla-central/rev/08126ef3b452

This issue is verified fixed using Firefox 90.0a1 (BuildId:20210421095627) on macOS 10.15 & 11.3

The patch landed in nightly and beta is affected.
:mstange, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Beta status is currently "disabled" because bug 1700679 hasn't been uplifted yet. Once it is, the Beta status becomes "affected" and then "fixed" because the fix from this bug will be uplifted along with bug 1700679.

https://hg.mozilla.org/releases/mozilla-beta/rev/f0f57952446d

This issue is verified fixed using Firefox 89.0b8 (BuildId:20210504185920) on macOS 10.15