Switch from `Op`/`MiscOp`/`ThreadOp` to just `Opcode` everywhere, and
get rid of methods that are no longer needed.
Remove the now-unnecessary ExtraConversionOperator node.
Differential Revision: https://phabricator.services.mozilla.com/D58941
--HG--
extra : moz-landing-system : lando
The `Opcode` wraps an `Op`, and if the `Op` is a prefix it also
carries the secondary opcode bits. Implicit constructors from `Op`,
`MiscOp`, etc to `Opcode`, ensures that this will be pretty painless
to use.
Differential Revision: https://phabricator.services.mozilla.com/D58940
--HG--
extra : moz-landing-system : lando
We are getting this exception because we return false here and do not perform
the microtask checkpoint when CycleCollectedJSContext::runJobs executes, but
the contract of runJobs() _requires_ that the microtask queue be empty after
is has completed execution.
CycleCollectedJSContext::RecursionDepth() returns the depth taking the debugger
recursion depth and the thread recursion depth into account, however when
used here, mTargetedMicroTaskRecursionDepth is expects to only be compared
against the thread recursion depth
Differential Revision: https://phabricator.services.mozilla.com/D58901
--HG--
extra : moz-landing-system : lando
When media element is inactive, asking MDSM to seek is actually useless, because all the data we decode won't be showed to user. In addition, we have to store extra pending events for `seeking` and `seeked`, which might result in memory overflow if the inactive page is calling `seek()` all the time.
Therfore, we should delay all seeking tasks while media is inactive, and perform the latest seeking task when media becomes active.
Differential Revision: https://phabricator.services.mozilla.com/D58918
--HG--
extra : moz-landing-system : lando
Two parameters in `SuspendOrResumeElement()` are acutally the same, they are both related with `IsActive()`, so using one parameter is enough.
In addition, we only suspend or resume element by checking element's active state, so rename `mPausedForInactiveDocumentOrChannel` to `mSuspendedForInactiveDocument` which fits the actual situation more.
Differential Revision: https://phabricator.services.mozilla.com/D58749
--HG--
extra : moz-landing-system : lando
This patch is not ideal: if would be better to do the defaulting in
`toolkit/moz.configure`, but doing it there runs into problems with base
toolchain configurations, as the clang there is not new enough. So we
have this, doing everything with environment variables, which is easily
turned on or off, depending on the needs of the specific configuration.
The `mozconfig.no-compile` change is not really needed, as the wasm
sandboxing detection bits are not conditional on
`--enable-compile-environment`. Those bits should be, and I will tackle
doing that after the holidays.
Differential Revision: https://phabricator.services.mozilla.com/D58102
--HG--
extra : moz-landing-system : lando
https://hg.mozilla.org/mozilla-central/rev/234701139a2a61d1262e609c9d8ac42384ecafda
Removed the following CSS rule:
#iconContainer {
-moz-box-pack: center;
min-height: 55px; /* maximum icon height + icon margin */
min-width: 58px; /* maximum icon width + icon margin */
}
Which enforced the size of the icon row.
The icon loads asynchronously, so by the first time we fire DOMContentLoaded it
may not have loaded yet. This means that sizeToContent() will size the window to
an smaller size and stuff will wrap around when it loads.
<image> doesn't block onload so even delaying this wouldn't work.
Restore the wrapper to ensure loading the icon or not doesn't affect layout of
the dialog.
Differential Revision: https://phabricator.services.mozilla.com/D58705
--HG--
extra : moz-landing-system : lando
We currently do a process switch for a failed load so that we show an error page in the right process. This adds an exception for loads that we just explicitly cancelled, since it shouldn't be necessary, and so that tests that use BrowserUtils.waitForDocLoadAndStopIt don't get confused.
Differential Revision: https://phabricator.services.mozilla.com/D58889
--HG--
extra : moz-landing-system : lando
The extra onSecurityChange message comes from the process switch, and this patch queue changes the timing of when that happens (to be once we receive a response, not before the load starts).
Differential Revision: https://phabricator.services.mozilla.com/D58888
--HG--
extra : moz-landing-system : lando
This doesn't block the STATE_START notification from the new process, as we currently have a second start notification (when DocumentChannel redirects to the real channel), so this is unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D56818
--HG--
extra : moz-landing-system : lando
Now that everything in `GeckoProcessManager` runs on the XPCOM launcher thread,
`GeckoThread` should just call `GeckoProcessManager.preload()` directly.
Differential Revision: https://phabricator.services.mozilla.com/D57840
--HG--
extra : moz-landing-system : lando
The primary purpose of this patch is to convert the internal sequence of
service binding and invoking of `start` to asynchronously run on the XPCOM
launcher thread via `GeckoResult`. Because more of the code now runs on the same
thread, many of these methods no longer need to be `synchronized`.
Disconnecting via `unbind` is also modified to use the launcher thread and
`GeckoResult`.
Note that no changes have been made yet to enable multiple processes of the
same type; those changes will be made in bug 1595834.
Differential Revision: https://phabricator.services.mozilla.com/D57839
--HG--
extra : moz-landing-system : lando
This patch adds a `Dispatcher` implementation that allows us to create
`GeckoResult`s that will dispatch to the XPCOM launcher thread.
Differential Revision: https://phabricator.services.mozilla.com/D57838
--HG--
extra : moz-landing-system : lando
Since `XPCOMEventTarget` uses JNI, this patch makes it possible for consumers to
retrieve and invoke methods on one without needing to worry about whether JNI
is actually up yet.
To achieve this, we create the `IXPCOMEventTarget` interface, and observe that
both of its methods can be handled by a proxy if JNI is not ready:
* Calls to `dispatch` may be enqueued until JNI is up;
* Observe that, when JNI is not up yet, the result of `isOnCurrentThread`
can never be `true`.
Once JNI is up and the event targets have been resolved, the proxies are
replaced with the real, concrete `XPCOMEventTarget`s and are no longer used for
the remainder of the Gecko instance's lifetime.
Differential Revision: https://phabricator.services.mozilla.com/D57837
--HG--
extra : moz-landing-system : lando
Changes:
Run `web-platform-tests-crashtests`, `web-platform-tests-reftests` with ubuntu1804 docker image.
This is a piecemeal migration, since the main `web-platform-tests` is not ready for ubuntu1804 yet due to several issues.
Depends on D59386.
Differential Revision: https://phabricator.services.mozilla.com/D59403
--HG--
extra : moz-landing-system : lando
When we let the WebIDL callback wrapper report exceptions, it returns an error
result of NS_ERROR_UNEXPECTED, which winds up getting set as a promise
rejection reason or re-reported to the console. This just causes unnecessary
confusion for callers, especially since the error has no location information.
Differential Revision: https://phabricator.services.mozilla.com/D57657
--HG--
extra : moz-landing-system : lando
Changes:
Run mochitest-webgl suites on ubuntu1804.
Update the expectation of a test to remove the `headless` specification.
Differential Revision: https://phabricator.services.mozilla.com/D59401
--HG--
extra : moz-landing-system : lando
Changes:
Run `mochitest-a11y` on ubuntu1804 image.
On the `ubuntu1804` image, bug 1429575 is a relatively frequent occurrence.
Differential Revision: https://phabricator.services.mozilla.com/D59220
--HG--
extra : moz-landing-system : lando