irrespective of the optimization level. The code was previously using
the optimization level as a proxy for whether --enable-release is
enabled or not, which was invalidated by bug 1689284.
Differential Revision: https://phabricator.services.mozilla.com/D113730
This will tie the version used for CI lints to the version of rust used
for builds on CI.
Bonus point: we can now have rustfmt and clippy on Windows and mac,
which allows to run the corresponding mozlint unit tests on those
platforms.
Differential Revision: https://phabricator.services.mozilla.com/D113905
While here, remove the unused clippyProcess.config. And because we need
to manipulate `$PATH` before running `cargo`, use the same wrapping
function in `get_clippy_version`.
Differential Revision: https://phabricator.services.mozilla.com/D113902
Marionette enables itself only when --marionette is passed in. Given that
command line arguments can only be passed in using the debug configuration, it
is safe to send this event all the time.
Differential Revision: https://phabricator.services.mozilla.com/D113829
This test was added in Bug 1651420, and then broken silently, due to an error
in the activation of the test by Bug 1653567. This edge case behaviour
shouldn't block us from landing private fields and methods
Tracking fixing this I have opened Bug 1708812.
Differential Revision: https://phabricator.services.mozilla.com/D114016
It looks like it was too hopeful that we would be able to get rid of all usage
of GfxInfo::Init() from content process. Since it looks like there may be
some rare cases where the browser asserts, we should preface the assertions
to only happen with Win32k lockdown enabled to allow the user to continue
to use their browser while foxfooding this feature.
Differential Revision: https://phabricator.services.mozilla.com/D113984
This doesn't seem a recent regression, the underlying issue is that we don't account for
the Extensions content scripts (and user scripts) as other principals that may be able
to intercept a drop event and then try to access the dataTransfer.files property before
the webpage does.
As the big inline comment inside DataTransferItemList::Files does explain, keeping a copy
of the FileList when accessed from a webpage principal is necessary for spec compliance,
while we don't cache it when it is being accessed by system principal code.
(see https://searchfox.org/mozilla-central/rev/6cbe34b441f7c7c29cd1e5f0e19c7000142f1423/dom/events/DataTransferItemList.cpp#200-242)
The changes in this patch are preventing us from caching the file list also when accessed
by expanded principals (which are never going to be used for any web page, but they are used
by both Extensions content scripts and Extensions user scripts), along with adding a new.
regression test to prevent it from regressing without being noticed.
Without this patch, when an extension content script or user script does intercept the
drop event and access the dataTransfer.files property, we cache the FileList created
for the ExpandedPrincipal associated to the Extension script and after that if the page
try to access it we do return null because the webpage principal doesn't subsume the
expanded principal (which is also why the issue isn't triggered if the webpage does
access it first). In debug build we crash because we hit the assertion in
DataTransferItemList::Files right before the earlier nullptr return we hit on release.
Differential Revision: https://phabricator.services.mozilla.com/D113555
This patch does prevent about:addons "Manage Extension Shortcuts" view to miss to catch
shortcut conflicts due to the special meaning of "Ctrl" on macOS systems, and its
implicit conversion into "Command":
- As the [documentation on MDN explicitly mention](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/commands#key_combinations):
> On Macs, "Ctrl" is interpreted as "Command", so if you actually need "Ctrl", specify "MacCtrl".
- and so ExtensionShortcuts.buildKeyFromShortcut calls ShortcutUtils.getModifiersAttribute ([1])
which convert both Ctrl and Command are into the same accel modifier, which is what ends into the key element
appended into the chrome window document.
- but we still have the original "Ctrl" as part of the shortcut string that
ExtensionShortcuts keeps into its map of the defined shortcuts loaded from
the extension manifests and from the one stored on disk (through ExtensionSettingsStore)
- when the about:addons "Manage Extension Shortcuts" view receive a new shortcut
from the user, it does convert the accelKey property from the dom event received
into "Command", and then it does check if the shortcut string exists in the
map of the existing shortcuts.
- when the extension using the same shortcut does use "Ctrl+..." in its commands
suggested shortcuts, shortcuts.js (the "Manage Extension Shortcuts" view implementation
script) wouldn't find the "Command+..." shortcut in the map of the existing shortcuts
and it would assume that it is not used and let the user to set a duplicate shortcut
without any of the warnings or errors expected.
The approach in this patch does abstract out the shortcutKeyMap used in
the about:addons shortcuts.js script into a specialized DefaultMap subclass,
which does internally does a "platform specific" normalization of the given
shortcutString to make sure that we don't miss duplicated shortcuts on macOS
due to the implicit convertion of the Ctrl modifier key.
[1]: https://searchfox.org/mozilla-central/rev/3aef835f6cb12e607154d56d68726767172571e4/toolkit/modules/ShortcutUtils.jsm#185-212
Differential Revision: https://phabricator.services.mozilla.com/D113698
There's a ridealong change here to fix up some rules around the local one-offs. There's a rule to make the bookmark button when selected. I made that fill use --urlbar-icon-fill-opacity and also removed related rules for the tabs one-offs. Those were holdovers from when the tabs one-off was green.
Differential Revision: https://phabricator.services.mozilla.com/D113986
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
Harry Twyford
emcminn
Mike Hommey
Toshihito Kikuchi
Emma Malysz
Jared Wein
Ting-Yu Lin
Agi Sferro
Matthew Gaudet
Henrik Skupin
Bas Schouten
Shane Caraveo
Punam Dahiya
Alexandre Lissy
Chris Martin
Luca Greco
Steven Michaud
Noemi Erli
Csoregi Natalia
Barret Rennie
Tim D. Smith
Jesse Schwartzentruber
Markus Stange