I'd like to implement a 'backstop' strategy, such that it will prevent all other
optimizers from removing tasks under certain conditions (e.g every 10th push).
The nicest way to implement this seems to be an 'All' composite strategy
(similar to 'Either' which this patch renames to 'Any'). This means we could
do something like:
All("seta", "backstop")
which means we would only remove tasks if *all* substrategies say to remove
tasks.
Differential Revision: https://phabricator.services.mozilla.com/D68620
--HG--
extra : moz-landing-system : lando
This fixes the user-facing issue. This skips the "open in window" and "open in
tab" tests because they're broken due to bug 1626573.
Differential Revision: https://phabricator.services.mozilla.com/D70937
--HG--
rename : browser/base/content/test/contextMenu/browser_canvas_view_image.js => browser/base/content/test/contextMenu/browser_view_image.js
extra : moz-landing-system : lando
This fixes the web-observable bits, but still not the context menu. Patch
incoming for that.
Differential Revision: https://phabricator.services.mozilla.com/D70936
--HG--
extra : moz-landing-system : lando
It's probably more helpful to have the variable documentation near the
declaration. Also amends the description to cover normal name assignments.
Depends on D70863
Differential Revision: https://phabricator.services.mozilla.com/D70864
--HG--
extra : moz-landing-system : lando
`~Maybe()` will perform the clean-up anyway, so we don't really need to call
`reset()` manually here.
Depends on D70862
Differential Revision: https://phabricator.services.mozilla.com/D70863
--HG--
extra : moz-landing-system : lando
The comment about handling name assignments separately predates `NameOpEmitter`.
Using `NameOpEmitter` we don't have to worry choosing the correct bytecode
operations and when to emit `BindName`.
Depends on D70861
Differential Revision: https://phabricator.services.mozilla.com/D70862
--HG--
extra : moz-landing-system : lando
Headers that are not present in the original request but are added by two or
more competing extensions are not merged, but only one of the changes is
applied. Since this causes issues with privacy and security enhancing
extensions trying to tighten up CSP, this introduces a special case to
explicitly always merge the CSP header.
Differential Revision: https://phabricator.services.mozilla.com/D63554
--HG--
extra : moz-landing-system : lando
When the pref is not set to true, we should not display the input,
but also the editor toolbar, the instant evaluation result and
the editor resizer.
The existing test is modified to ensure we cover all these elements.
Differential Revision: https://phabricator.services.mozilla.com/D70843
--HG--
extra : moz-landing-system : lando
Restricted to Nightly because there's still an open issue about inferred
function names and because the proposal was only recently moved to stage 3.
Depends on D70821
Differential Revision: https://phabricator.services.mozilla.com/D70823
--HG--
extra : moz-landing-system : lando
Implements the changes from: https://github.com/tc39/ecma262/pull/1408
The spec PR requires to start the non-syntactic `try` block before retrieving
the "return" property and checking whether or not the "return" property is
callable. As part of this change we can also reorder the other byte code
instructions, which enables us to make the code more similar to normal JS code.
The equivalent JS code is documented in the added comments. Furthermore these
changes allow us to remove the manual stack depth fixups.
Depends on D70819
Differential Revision: https://phabricator.services.mozilla.com/D70820
--HG--
extra : moz-landing-system : lando
Updates the two callers to `JSOp::Pick` which can be optimised to `JSOp::Swap`.
Using `JSOp::Swap` saves one byte when compared to `JSOp::Pick`.
Depends on D70817
Differential Revision: https://phabricator.services.mozilla.com/D70819
--HG--
extra : moz-landing-system : lando
Omit the ellipsis characters when the call has zero arguments. This makes the
disassembly of iterator code a bit more readable, because we're now no longer
displaying additional "..." strings when the call has no arguments.
Depends on D70816
Differential Revision: https://phabricator.services.mozilla.com/D70817
--HG--
extra : moz-landing-system : lando
Class instance fields can be named "static", so we need to handle the
following three cases:
- `TokenKind::Assign` (for `class { static = <expr>; }`),
- `TokenKind::Semi` (for: `class { static; }`),
- and `TokenKind::RightCurly` (for `class { static }`).
Depends on D70813
Differential Revision: https://phabricator.services.mozilla.com/D70814
--HG--
extra : moz-landing-system : lando
Two cases have been tested:
1. Right-click opening a blob URL
2. Right-click opening a blob URL, which points to a blob of type html, which fetches another blob URL
Depends on D69717
Differential Revision: https://phabricator.services.mozilla.com/D70197
--HG--
extra : moz-landing-system : lando
addA11yLoadEvent gets the contentWindow and wait for the document from that window to fire the load event.
Enabling the DocumentChannel for parent process load (or here in non-e10s mode) we have one extra event loop before the load starts.
So the window passed to addA11yLoadEvent would have been of the about:blank page.
The current code was based on an observable behaviour which was that the load was occuring synchronously.
DocumentChannel broke that assumption.
Differential Revision: https://phabricator.services.mozilla.com/D70799
--HG--
extra : moz-landing-system : lando
When starting a load via the ParentProcessDocumentChannel, the event http-on-modify-request will be fired before the DocumentLoadListener has a chance to set the notificationCallback attribute.
When using a DocumentChannel, this test will not trigger the expected codepath as the DOMWindowCreated event will be fired once the channel is fully up and running; which in effect is also a fix of the original bug 1339722
Instead we use the document-on-modify-request event when the DocumentChannel is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D70011
--HG--
extra : moz-landing-system : lando
Some tests rely on this event to start action. The DocumentChannel had no equivalent. We make the ParentProcessDocumentChannel listen to this event and if it matches the nsIChannel currently in use in the DocumentLoadListener than we emit a similar document-on-modify-request event on the DocumentChannel.
Differential Revision: https://phabricator.services.mozilla.com/D70010
--HG--
extra : moz-landing-system : lando
Add ParentProcessDocumentChannel object. This object is a DocumentChannel that will start a channel load from the parent process via a DocumentChannel.
The aim of this task is two-fold.
1- Be consistent on how we handle redirects before continuing the load on the final channel.
2- Prepare to initiate a process switch when needed without having to go via an intermediary content process, saving a process switch. This task will be done in a follow-up task.
The behaviour of the ParentProcessDocumentChannel is similar in logic to the DocumentChannelChild/DocumentChannelParent pair.
The ParentProcessDocumentChannel sets up a DocumentLoadListener, have it handle the redirects and upon completion continue the load on the final channel.
Differential Revision: https://phabricator.services.mozilla.com/D70009
--HG--
extra : moz-landing-system : lando
We must wait for the iframe created by extension1 to be fully loaded before we can attempt to send a message to it.
So we send a message when it is ready, and suspend the execution until this message is received.
Differential Revision: https://phabricator.services.mozilla.com/D70008
--HG--
extra : moz-landing-system : lando
The code assumed that nsJARChannel::RetargetDeliveryTo would have been called synchronously from nsJARChannel::OnStartRequest, which would be true if we weren't using a DocumentChannel.
The DocumentLoadListener queue the calls to OnStartRequest until the final redirect.
nsJARChannel::RetargetDelivery mRequest member is be set to forward the call.
So we need to only reset it once OnStopRequest has been received.
Differential Revision: https://phabricator.services.mozilla.com/D70007
--HG--
extra : moz-landing-system : lando
The DocumentLoadListener is setting up a ParentChannelListener to go in between the normal listener->channel chain.
ParentChannelListener not implementing nsIThreadRetargetableStreamListener would prevent a nsHtml5StreamParser settings things up so that OnDataAvailable could be sent to a html parser thread off the main thread; improving performance.
Differential Revision: https://phabricator.services.mozilla.com/D70006
--HG--
extra : moz-landing-system : lando
Following the changes to DocumentChannel the test was failing.
With DC, a load may take a few event loops to start. This current test was only waiting for the load to start to the URL about:preferences#privacy-logins and would immediately tear down the window.
However, this URL redirects to about:preferences#privacy ; destroying the window midway could cause XML parsing error.
So now we wait for the page to fully load, and make sure we've been through both addresses.
Differential Revision: https://phabricator.services.mozilla.com/D70003
--HG--
extra : moz-landing-system : lando
Regressiong from bug 1607987. This prevented from QueryInterface(Ci.nsIIdentChannel) in JS on the channel.
Differential Revision: https://phabricator.services.mozilla.com/D70002
--HG--
extra : moz-landing-system : lando
Andrew Halberstadt
Stefan Hindli
Gijs Kruitbosch
Emilio Cobos Álvarez
Luca Greco
Jonathan Kew
Johann Hofmann
emcminn
Tetsuharu Ohzeki
André Bargull
Andy Wingo
Andrea Marchesini
tobias
Daisuke Akatsuka
Nicolas Chevobbe
Subhamoy Sengupta
Kagami Sascha Rosylight
Ryan Pauls
Jean-Yves Avenard