`LauncherResult` only includes file and line info when built into the launcher
process. Now that there will be `xul.dll`-based code calling into launcher
process startup, this would create an ABI mismatch.
This patch creates a new type, `LauncherResultWithLineInfo`, that
unconditionally includes the file and line so that APIs called by both `xul`
and non-`xul` code can have the same ABI for both.
Differential Revision: https://phabricator.services.mozilla.com/D53677
--HG--
extra : moz-landing-system : lando
Now that the launcher blocklist will support child processes, we need to add
them to the launcher blocklist. The revised criteria the `Launcher` blocklist
matches the criteria already in use by the `Legacy` blocklist.
Differential Revision: https://phabricator.services.mozilla.com/D53675
--HG--
extra : moz-landing-system : lando
* We change `InitializeDllBlocklistOOP` to be able to set the correct flags
when initializing a sandbox child process.
* We change the freestanding DLL blocklist code to be sensitive to the
`CHILD_PROCESSES_ONLY` flag;
* We move the declaration of `gBlocklistInitFlags` to `WindowsDllBlocklist.h`
so that it is visible to more code.
Differential Revision: https://phabricator.services.mozilla.com/D53674
--HG--
extra : moz-landing-system : lando
When we initialize the legacy blocklisting code, we should carry forward any
flags that were set by the launcher process and/or sandbox launcher.
Differential Revision: https://phabricator.services.mozilla.com/D53672
--HG--
extra : moz-landing-system : lando
ContentTask tasks have a different lifetime than SpecialPowers tasks, with the
former being tied to the lifetime of a message manager and the latter tied to
the lifetime of a window global. That means that existing ContentTask callers
which expect to be able to register load listeners before the creation of a
window global, or which expect to persist after a page has navigated, won't
work as SpecialPowers tasks.
Since those sorts of tasks are not really resilient in the face of Fission,
they should really be written to work differently, but this patch mostly just
reverts them to using ContentTask for the time being.
Differential Revision: https://phabricator.services.mozilla.com/D53744
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
This patch updates the existing ContentTask.spawn rule to do similar things
for SpecialPowers.spawn calls, only with a slightly different set of globals.
Differential Revision: https://phabricator.services.mozilla.com/D53739
--HG--
extra : moz-landing-system : lando
This is somewhat unrelated, but I stumbled across it when writing part 1a, and
it annoyed me.
Differential Revision: https://phabricator.services.mozilla.com/D53737
--HG--
extra : moz-landing-system : lando
A number of additional globals are available to ContentTask.spawn tasks
compared to SpecialPowers.spawn tasks. Most of these are available by
accident, as a side-effect of running in a shared frame script global, or
being evaled in the context of the content-task.js frame script, but several
of them are pretty broadly useful, or difficult to obtain from a Sandbox
environment without reaching into arbitrary nearby globals.
This patch adds some of the more useful ones to the default task environment.
Differential Revision: https://phabricator.services.mozilla.com/D53736
--HG--
extra : moz-landing-system : lando
Some tests currently use an initial `ContentTask.spawn` call to import certain
modules into the frame script global that subsequent tasks will run in. Since
each `SpecialPowers.spawn` task runs in its own sandbox, this method doesn't
work for them.
This patch adds a helper, `SpecialPowers.addTaskImport`, which allows similar
functionality by automatically importing the given module for any task spawned
by the `SpecialPowers` instance it was called on.
Differential Revision: https://phabricator.services.mozilla.com/D53735
--HG--
extra : moz-landing-system : lando
ContentTask.spawn supports some common global mochitest assertion methods as
aliases for corresponding Assert methods, along with espected-fail `todo`
variants, and the `info` method for logging messages without triggering
assertions. The easiest way to mass-convert existing callers is to just add
support for these to SpecialPowers.spawn, which this patch does.
Differential Revision: https://phabricator.services.mozilla.com/D53734
--HG--
extra : moz-landing-system : lando
This lets us load Widevine versions that support av1. This doesn't add encrypted
av1 support, but is one of the steps needed to do so.
This adds some comments to better clarify the string literals found in the code
being updated.
Differential Revision: https://phabricator.services.mozilla.com/D56100
--HG--
extra : moz-landing-system : lando
There's a race condition where we decide we want to open a link in the 'current'
tab, but that tab has changed between when the user clicked the link, and when
we're processing the event. However, the event still knows where it came from,
and we can pass that along to 'openLinkIn' to ensure we open the link in the
correct window/tab.
Differential Revision: https://phabricator.services.mozilla.com/D56187
--HG--
extra : moz-landing-system : lando
We notice for some unknown gamepads, their axes don't follow the kAxisUsageMin rule, so we should choose to
use array index as the axis id.
Differential Revision: https://phabricator.services.mozilla.com/D56058
--HG--
extra : moz-landing-system : lando
The ref-types and multi-value compiler environment flags can be true even if they
are disabled by compile time flag. This mostly works for ref-types because all
new instructions are only decoded if the compile time flag is enabled. This does
not work for multi-value as it affects type validation.
Differential Revision: https://phabricator.services.mozilla.com/D55891
--HG--
extra : moz-landing-system : lando
This implements a 'fission-run-by-projects' and 'fission-tier' key that mirrors
the non-fission versions. We need to duplicate the keys rather than use
something like 'by-variant' due to the order that things are processed in the
tests.py transforms.
These keys should only be temporary until Fission is running the same as
non-Fission. In the meantime they will give us greater control over what runs
where.
The taskgraph generated before and after this change is identical.
Differential Revision: https://phabricator.services.mozilla.com/D56211
--HG--
extra : moz-landing-system : lando
These new methods will be automatically used by ARM targets for image
decoding. Specifically it should reduce the time required to decode GIFs
and opaque PNGs.
Differential Revision: https://phabricator.services.mozilla.com/D56030
--HG--
extra : moz-landing-system : lando
Changes:
These packages are not necessary for proper testing environment, and are pulled in by `ubuntu-desktop` metapackage. Purge them for the time being, at least until the more aggressive pruning and streamlining of the docker image can begin.
Differential Revision: https://phabricator.services.mozilla.com/D56227
--HG--
extra : moz-landing-system : lando
We wait for the crash to be recorded in the crash manager only for the
submission that will also be recorded. This is required because those crashes
are either content or plug-in crashes and the crash manager is aware of them.
Crash reports submitted from about:crashes are not recorded because they are
not known to the crash manager and thus we shouldn't wait for them.
Differential Revision: https://phabricator.services.mozilla.com/D55971
--HG--
extra : moz-landing-system : lando
Changes UpdatePing.jsm so it observes 'update-staged' notifications and adds a test so this shouldn't break in the future
Differential Revision: https://phabricator.services.mozilla.com/D56155
--HG--
rename : toolkit/mozapps/update/tests/browser/browser_telemetry_updatePing_ready.js => toolkit/mozapps/update/tests/browser/browser_telemetry_updatePing_downloaded_ready.js
rename : toolkit/mozapps/update/tests/browser/browser_telemetry_updatePing_ready.js => toolkit/mozapps/update/tests/browser/browser_telemetry_updatePing_staged_ready.js
extra : moz-landing-system : lando
This methods is then used in Netmonitor and Animation
panel, where we already had similar functions.
Differential Revision: https://phabricator.services.mozilla.com/D56167
--HG--
extra : moz-landing-system : lando
In preparation for deferring the allocation of Scopes to the end of bytecode
emission, we introduce AbstractScope, which is a facade class for use within
the BytecodeEmitter. This class allows asking the same set of queries that are
asked of Scopes, but when we defer the allocation of Scopes, we may not choose
to answer the queries with a Scope, instead using a (to be implemented)
ScopeCreationData.
Differential Revision: https://phabricator.services.mozilla.com/D51911
--HG--
extra : moz-landing-system : lando
We've been using the "FirefoxMessageWindow" class for this, but it no longer
exists as of bug 1518639, so switch to classes that should always be there.
Differential Revision: https://phabricator.services.mozilla.com/D56099
--HG--
extra : moz-landing-system : lando
Aaron Klotz
Kris Maglione
Jonathan Kew
Manish Goregaokar
Bryce Seager van Dyk
Arthur Iakab
Gijs Kruitbosch
Jim Porter
Daosheng Mu
Ryan Hunt
Andrew Halberstadt
Emma Malysz
Andrew Osmond
Edwin Takahashi
Scott
Mellina Y.
Daniel Varga
Brian Hackett
Tom Schuster
Gabriele Svelto
David Major
Robert Strong
Timothy Nikkel
Nicolas Chevobbe
Matthew Gaudet
Molly Howell