This will be useful for native context menus: We can call OnOpen() before we
ask the OS to open the menu. This way, popupshowing handlers can prevent the
menu from opening.
I was also planning to use this to call OnOpen during menuNeedsUpdate, which is
where the Apple docs say we should do our menu modifications. However, doing so
has some other effects so I will hold off on making that change.
This patch also clarifies our inability to interfere with menu opening, which
clashes a little bit with the cross-platform expectations around popupshowing
events, but should hopefully not make a difference in practice.
Differential Revision: https://phabricator.services.mozilla.com/D108721
This will be used for native context menus. I'm planning for nsMenuPopupFrame to
be the owner of the NativeMenu, and it only wants to keep the object around
while the menu is open. So it needs to be notified when it closes.
Differential Revision: https://phabricator.services.mozilla.com/D109178
If a menu item is clicked, macOS calls menuDidClose before it calls menuItemHit.
This means that, before this patch, we would fire the popuphiding event before
we run the command handler for the clicked menu item.
This seems to work fine for the menubar menus, but it causes problems for
context menus: We have a lot of front-end code that expects item command
handlers to be run *before* popuphiding handlers. For example, for the content
area context menu, many commands use gContextMenu in their implementation and
expect gContextMenu to be non-null. But gContextMenu is set to null in the
popuphiding handler.
So we need to reverse the native order of events.
Using a runnable for MenuClosedAsync() delays the popuphiding event just enough
that menuItemHit can run first.
Differential Revision: https://phabricator.services.mozilla.com/D108722
The implementation for this method is long gone, and it wasn't called anywhere,
so the compiler and linker didn't notice anything wrong.
Depends on D109173
Differential Revision: https://phabricator.services.mozilla.com/D109174
NativeMenuMac implements a new mozilla::widget::NativeMenu interface.
This interface is intended to be used by cross-platform C++ code.
nsStandaloneNativeMenu is now only used to implement the IDL interface (which
is used from JavaScript code), and C++ code can use NativeMenu with its more
ergonomic C++ interface.
Differential Revision: https://phabricator.services.mozilla.com/D109173
They all contained the same menu group owner pointer anyway, and nothing else.
Differentiating menu items is done based on the item's tag, not based on its
representedObject.
Depends on D109122
Differential Revision: https://phabricator.services.mozilla.com/D109123
In the case of nsStandaloneNativeMenu, the root nsMenuX has the nsStandaloneNativeMenu as its parent.
But the parent's NativeNSMenu() is the root nsMenuX's NativeNSMenu().
So when we were removing the collapsed="true" attribute from the root nsMenuX of an nsStandaloneNativeMenu,
`parentMenu` and `mNativeMenu` were the same object. So we would insert mNativeMenuItem into mNativeMenu (as a subitem),
and then also set mNativeMenuItem.submenu = mNativeMenu, creating a cyclic menu structure.
I've added a test for this scenario.
It turns out though that without this patch, the test doesn't actually fail, because the collapsed attribute
handling also calls SetRebuild(true). So while the test would briefly create the cyclic structure, this
bug would be corrected by the MenuOpened calls which would rebuild the menu contents, and then all the
checks from the test would still succeed.
Depends on D109113
Differential Revision: https://phabricator.services.mozilla.com/D109114
Websites like Reddit and Slack call Object.assign thousands of times. The vast majority
of these calls (more than 95%) are with plain objects. This patch adds a fast path for
this case.
This lets us bypass the generic SetProperty code and some of the JSClass checks
that aren't relevant for PlainObject.
Differential Revision: https://phabricator.services.mozilla.com/D108408
NativeObject::addEnumerableDataProperty is very hot and this is a measurable speedup
because it's not as branchy as setLastProperty.
Depends on D108405
Differential Revision: https://phabricator.services.mozilla.com/D108406
One of the advantages of the Shape/BaseShape overhaul is that non-dictionary
shapes never change their BaseShape, because the BaseShape no longer contains
the ShapeTable and "owned" BaseShapes don't exist anymore.
This lets us simplify some comments and code.
Differential Revision: https://phabricator.services.mozilla.com/D108405
Checking for proxies was slowing us down for no good reason. Non-native objects
already manage their own layout; slotSpan only applies to native objects.
Differential Revision: https://phabricator.services.mozilla.com/D108404
When we had unboxed objects, not every object had a shape, but now we can just
do a shape check without checking it's a NativeObject first.
Differential Revision: https://phabricator.services.mozilla.com/D108403
Also make CompactPair<A, B> a literal type if A and B are literal types,
and add MaybeStorageBase that ought to be used as a basis of MaybeStorage
in a follow-up patch.
Differential Revision: https://phabricator.services.mozilla.com/D55930
Confirmed that the change work on Mali-400 MP device.
GLContextProviderEGL::CreateForCompositorWidget() with aWebRender=true failed to create GLContext when GLES3 is not supported on device. When aWebRender=false, it does not request depth buffer nor GLES3. Though when android device supports GLES3, GLES3 context was created on android devices that I tested.
Differential Revision: https://phabricator.services.mozilla.com/D109015
