This patch also removes the pref widget.system-colors-follow-theme, which was
only true on macOS. System colors now follow the global Firefox theme.
Differential Revision: https://phabricator.services.mozilla.com/D117098
I didn't add this check originally because the thinking was that macOS wouldn't dispatch
these events to us anyway as long as a menu is open.
However, our menu opening is asynchronous. So we can still get wheel events between the
mousedown that asks to open the menu, and the delayed perform which then ends up opening
the menu for real. We don't want to cancel opening when we get these straggler events.
Differential Revision: https://phabricator.services.mozilla.com/D115763
Like the other browsers, we should stop dispatching a set of composition
events when `insertText:` is called by Emoji picker, accent character
picker of some Western keyboard layouts. Then, corresponding
`beforeinput` event becomes cancelable like the other browsers'.
Differential Revision: https://phabricator.services.mozilla.com/D114827
During fullscreen transitions on Mac, ignore occlusion events caused by the widget DOM fullscreen transition effect which uses a temporary window.
Add a test that attempts to enter fullscreen from a non-focused window. This test is to ensure the fix (and future fixes) do not regress the focus requirement for fullscreen.
Differential Revision: https://phabricator.services.mozilla.com/D115046
Like the other browsers, we should stop dispatching a set of composition
events when `insertText:` is called by Emoji picker, accent character
picker of some Western keyboard layouts. Then, corresponding
`beforeinput` event becomes cancelable like the other browsers'.
Differential Revision: https://phabricator.services.mozilla.com/D114827
This affects both native context menus and menubar menus.
Doing a flush here is fine, the nsMenuX constructor already flushes via SetupIcon()
(which also uses nsComputedDOMStyle, in nsMenuItemIconX::GetIconURI).
Differential Revision: https://phabricator.services.mozilla.com/D114785
This patch also fixes an issue where hidden native items could be activated, and makes the
error message consistent between both implementations in this case.
Differential Revision: https://phabricator.services.mozilla.com/D114503
When I initially implemented it for GTK, I just followed the Highlight color
everywhere, but on macOS it makes of course a lot of sense to use
NSColor.controlAccentColor.
Differential Revision: https://phabricator.services.mozilla.com/D114430
This can be disabled by setting the following pref to false:
widget.macos.enable-pre-bigsur-workaround-for-dark-mode-context-menus
Differential Revision: https://phabricator.services.mozilla.com/D114037
This avoids bugs where a menu close request (cancelTrackingWithoutAnimation) would be dropped
if the command event did certain unexpected things. I'm not 100% sure what the exact
circumstances for the bad behavior were (see bug 1707598 comment 7 for details), but
this seems like the right thing to do anyway.
We also need to delay the call to MenuClosedAsync, because MenuClosedAsync flushes any pending
command runnables (so that the command event fires before popuphiding / popuphidden). However, we
can only delay the call to MenuClosedAsync if we know thath the entire menu closes, and not just a
submenu.
Differential Revision: https://phabricator.services.mozilla.com/D113734
In the next patch, it will make different decisions for how to dispatch the
MenuClosedAsync event based on this flag.
Depends on D113987
Differential Revision: https://phabricator.services.mozilla.com/D113988
This also makes sure we call ActivateItemAfterMenuClosing on the submenu that
immediately contains the activated menu item, and not on the root menu.
This usually doesn't make a difference, except in the case where something
calls FlushMenuClosedRunnable afterwards; in that case, before this patch, we
might accidentally fired the popuphidden event for the submenu before the
command event for the clicked item.
Depends on D113733
Differential Revision: https://phabricator.services.mozilla.com/D113987
This is a robust way to queue runnables which won't run until after the nested
event loop of the open NSMenu has been exited.
NS_DispatchToCurrentThread is not a reliable way to achieve that, because it
puts the runnables into the Gecko event loop, and there's nothing that prevents
us from potentially visiting the Gecko event loop inside the NSMenu's event loop,
even after cancelTracking(WithoutAnimation) has been called.
Differential Revision: https://phabricator.services.mozilla.com/D113733
It doesn't need to be cancelable - the Run() method already nulls out mMenuItem,
so once Run() has been called once, it won't do anything on subsequent invocations.
This patch also improves safety a bit, by moving the pending command runnables
out of the mPendingCommandRunnables field before running them, so that the Run()
method has no way of invalidating the array that's being iterated over.
Differential Revision: https://phabricator.services.mozilla.com/D113732
Otherwise the singleton would be leaked. It's not a lot of bytes, but a future
patch in this series is going to add an nsDeque member to this class, and
nsDeque has leak detection which would cause test failures in debug builds if
we didn't clean up MOZMenuOpeningCoordinator on shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D113731
On CI, where we open and close menu items in quick succession, we sometimes got
into a state where the new menu was opened while we were still in the old menu's
nested event loop. So we had the following sequence of events:
```
- old menu +[NSMenu popUpContextMenu:withEvent:forView:]
- nested event loop for old menu
- old menu -[NSMenu cancelTrackingWithoutAnimation]
- new menu +[NSMenu popUpContextMenu:withEvent:forView:]
- nested event loop for new menu
- new menu -[NSMenu cancelTrackingWithoutAnimation]
- new menu's event loop is exited, but old menu's event loop remains on the
stack
- shutdown hang here
```
MOZMenuOpeningCoordinator makes sure that +[NSMenu popUpContextMenu:withEvent:forView:]
is always called in sequence, never in a nested fashion.
Differential Revision: https://phabricator.services.mozilla.com/D113373
This is what Safari does, i.e. once after a swipe gesture has started to a
direction where there is no navigation history, then even if the swipe gesture
switched to the opposite direction where navigation can happen, swipe navigation
will never happen. Chrome looks like they are trying to do swipe navigation in
such cases, but it looks like they sometimes fail it, the swipe navigation
indicator (an arrow image) doesn't show up sometime when the swipe navigation
goes to the opposite direction.
This change fixes stuck-in-overscroll situations where user swipes horizontally
to a direction where navigation is impossible during overscrolling, but doesn't
fix situations where navigation is possible but the user cancels the navigation.
To fix the later situations we need a different fix apart from this change.
The mochitest in this change doesn't test the stuck-in-overscroll situations at
all because we need to write a browser mochitest since swipe gesture is
implemented as a browser feature but unfortunately SpecialPowers.snapshotWindow
doesn't capture overscrolled gutter regions for some reasons, so instead the
test checks whether the swipe gesture module keeps capturing wheel events in the
situations where navigation is impossible.
Differential Revision: https://phabricator.services.mozilla.com/D113636
Stephen A Pohl
Tooru Fujisawa
Markus Stange
Andi-Bogdan Postelnicu
Harry Twyford
Noemi Erli
Kartikaya Gupta
Jonathan Watt
Butkovits Atila
Masayuki Nakano
Haik Aftandilian
Andrew Osmond
Neil Deakin
Emilio Cobos Álvarez
Hiroyuki Ikezoe
Cosmin Sabou