Since partials have started verifying signatures, the partial task has been failing in
`mach try scriptworker`. Since we are not concerned with the partial task itself,
split the tasks into two groups, so that it does not need to run.
Differential Revision: https://phabricator.services.mozilla.com/D83370
Doing this means that make will correctly understand that the underlying
program has changed and therefore it needs to trigger install rules.
Differential Revision: https://phabricator.services.mozilla.com/D83326
- Add macOS-specific function to retrieve the paper list for a given printer.
- Add JS test to ensure papers are initialized with valid values.
Differential Revision: https://phabricator.services.mozilla.com/D82598
These classes are both 'final', so it's pointless for them to declare their own
(non-overriding) virtual functions. They can't have any subclasses, so it would
be impossible for there to be polymorphism in these virtual funtions'
implementation. So, let's de-virtualize them.
(I'm guessing these date from the early Mozilla days when methods needed to be
virtual in order to be called from other components, or something like that.)
Differential Revision: https://phabricator.services.mozilla.com/D83234
When using the `tabs.query` API in a popup (e.g. a browserAction popup)
extensions expects to refer to the window where the popup is.
On mobile we don't really have a concept of window in the way that extensions
expect us to have, we also treat all tabs as belonging to separate tabs.
To make the behavior of the extension API more consistent with desktop, we
pretend that the popup belongs to whatever the top tab is at the time.
Differential Revision: https://phabricator.services.mozilla.com/D82769
We use this object on the Java side to open the popup and without this change
we don't look at the default popup URL when the tab-specific one is not
defined.
Differential Revision: https://phabricator.services.mozilla.com/D82767
The previous code, emitting the event from Toolbox.onTargetAvailable,
wasn't waiting for the call to TargetList.startListening which is done
from TargetList.onTargetAvailable.
Differential Revision: https://phabricator.services.mozilla.com/D82664
If we're going to ditch the old breakpad dump-syms from the build, people
are going to need have this locally if they ever want to build packages,
etc.
Differential Revision: https://phabricator.services.mozilla.com/D83150
Changes:
- removes the ability to schedule web-platform-tests-reftest-backlog and web-platform-tests-backlog from non-opt variants of each platform.
- in addition, removes the ability to schedule the above from windows7-32, regardless of the variant.
- clean up references to now-deprecated platforms in backlog task definitions.
Differential Revision: https://phabricator.services.mozilla.com/D83172
I based the InliningTree / CompileInfo code on IonBuilder::inlineScriptedCall.
In the future, if we want to inline cases where we didn't allocate a new ICScript, it should just be a matter of changing a few lines in maybeInlineIC. We can use the default ICScript off the target script.
(Note: we now check in maybeInlineCall that we don't already have a CallInlinedFunction. This should not normally happen, but could happen if we reset the warmup counter for a script.)
Differential Revision: https://phabricator.services.mozilla.com/D83184
When taking a snapshot for inlining, we have to read the CacheIR to find the ICScript and the target. We could store the target in another field in CallInlinedFunction, but that could be awkward in the future if we want to inline without trial inlining, because we won't have a CallInlinedFunction available. Instead, I hoisted the CacheIR-reading code in maybeInlineCall into its own function that can be shared by TrialInlining and the snapshot code.
Differential Revision: https://phabricator.services.mozilla.com/D83183
Preparing for inlining, at which point the WarpSnapshot / WarpScriptSnapshot relationship is no longer 1-to-1.
Depends on D83180
Differential Revision: https://phabricator.services.mozilla.com/D83182
Almost all of the data in WarpBuilder was already script-specific, so instead of renaming it to WarpScriptBuilder everywhere, I pulled out a WarpCompilation class to hold the data that is shared between scripts.
Differential Revision: https://phabricator.services.mozilla.com/D83180
