We have more readable and faster versions (that just omit the namespace
arg).
Mostly done via sed, with a couple helpers to use the faster lookups
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D181795
I'm about to extend them for bug 1811486, where I want to force in some
cases the rolled up popups to hide synchronously. These APIs use a ton
of boolean arguments that make them error prone, so refactor them a bit
to use strongly typed enums and flags.
Differential Revision: https://phabricator.services.mozilla.com/D167381
I'm about to extend them for bug 1811486, where I want to force in some
cases the rolled up popups to hide synchronously. These APIs use a ton
of boolean arguments that make them error prone, so refactor them a bit
to use strongly typed enums and flags.
Differential Revision: https://phabricator.services.mozilla.com/D167381
I'm about to extend them for bug 1811486, where I want to force in some
cases the rolled up popups to hide synchronously. These APIs use a ton
of boolean arguments that make them error prone, so refactor them a bit
to use strongly typed enums and flags.
Differential Revision: https://phabricator.services.mozilla.com/D167381
This patch aligns the code paths for programmatic menu item activation and
user-initiated menu item activation.
Before this patch, user-initiated menu item activation caused
the command event to fire synchronously from menuItemHit.
After this patch, the command event fires from MenuClosedAsync,
which, if an item was activated, is called asynchronously once
the menu's nested event loop has been exited. (If no item has been
activated, MenuClosedAsync is called *inside* the menu's event
loop so that popuphiding / popuphidden events for submenus don't
get delayed.)
This patch makes three major changes to align the two code paths:
- menuItemHit now calls ActivateItemAfterClosing. This fixes bug 1748815.
- NativeMenuMac::ActivateItem (used in automated tests) calls the
relevant methods in the same order as user-initiated item activation.
This means that what we're testing is now closer to what we're shipping.
This patch also removes the call to runAfterMenuClosed. The runnable
that calls MenuClosedAsync is already guaranteed to run outside the
menu's event loop when a menu item was activated (I'm 99% sure about this):
For user-initiated activations, the macOS code exits the loop immediately
after calling menuItemHit and doesn't give our CFRunLoopSource another
chance to run until the stack is unwound. For test-initiated activations,
we set MOZMenuOpeningCoordinator.needToUnwindForMenuClosing which tells
our native event loop to not run anything until the stack is unwound.
Differential Revision: https://phabricator.services.mozilla.com/D149316
ActivateItemAfterClosing is currently only called during automated tests.
Before this patch, the DoCommandRunnable could be run from two different places:
Either from the regular event loop (dispatched in `-[MOZMenuOpeningCoordinator _runMenu]`
once the menu event loop is exited), or from MenuClosedAsync, whichever happens first.
MenuClosedAsync always runs when the menu closes, so we can rely on
it being called after ActivateItemAfterClosing.
So we can simplify the code by just always firing the command event
from MenuClosedAsync.
Differential Revision: https://phabricator.services.mozilla.com/D149315
None of the consumer need to mutate styles, and this saves some ugly
const_casting on the next patch.
Doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D147555
This will make implementing the new behavior behind a pref
really straight-forward, and is generally nicer.
Depends on D121858
Differential Revision: https://phabricator.services.mozilla.com/D121705
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 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
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
This is exercised by one of the subtests of
browser/components/extensions/test/browser/browser_ext_menus_replace_menu.js :
The menu is opened while it's empty, and then the content items are added
asynchronously while the menu is open.
If we try to open an NSMenu with zero NSMenuItems, macOS immediately closes the
menu after opening it. With a placeholder item it stays open as expected.
Differential Revision: https://phabricator.services.mozilla.com/D112458
This will make a difference once code inside MenuChildChangedVisibility starts
calling IsVisible(). The method name has "Changed" in it, so it should be called
after the change.
Differential Revision: https://phabricator.services.mozilla.com/D112453
Before, we were only calling SetUpIcon if the item was visible during menu
construction on menu opening, but not if the item became visible after menu
opening.
Differential Revision: https://phabricator.services.mozilla.com/D112452
This means that it'll happen even if the menu item is not visible. This will make
it possible to make a menu item visible after initial menu construction.
Differential Revision: https://phabricator.services.mozilla.com/D112448
This will cause nsXULPopupManager to change the state to "open" before the
popupshown event fires. This is consistent with non-native menus.
This was caught by dom/html/test/browser_content_contextmenu_userinput.js.
Differential Revision: https://phabricator.services.mozilla.com/D111766
The asynchronous aspects of this are somewhat messy.
Hiding the menu visually before executing the command event is necessary for
the test browser/components/places/tests/browser/browser_library_bookmark_pages.js
which opens a modal sheet from a command event, and the modal has a nested event
loop.
Flushing command events before MenuClosedAsync is necessary for the test
browser/base/content/test/contextMenu/browser_contextmenu_linkopen.js, which
calls hidePopup right after it calls menuitem.click(); without the flushing,
the call to hidePopup would run the popuphiding/popuphidden events before the
command event and the command event handler would fail.
Differential Revision: https://phabricator.services.mozilla.com/D111520
Mike Hommey
Eitan Isaacson
Emilio Cobos Álvarez
nicklas boman
Stephen A Pohl
Iulian Moraru
Butkovits Atila
Markus Stange
Kagami Sascha Rosylight