This patch integrates the majority of the mach-perftest-notebook project from the github project to the in-tree mozperftest package/tool. Certain portions of it are disabled in this integration (posting to iodide, and transform searching).
Differential Revision: https://phabricator.services.mozilla.com/D70134
--HG--
extra : moz-landing-system : lando
There is actually possible to start the listener already while running `SuspendOrResumeElement()`, so we should remove the assertion and use a check instead.
Eg. JS can call `play()`, which would start the listener, before we run this method. This situation can be found when browsing Youtube on the GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D69673
--HG--
extra : moz-landing-system : lando
When the docShell's `SuspendMediaWhenInactive` flag is true, no media should be allowed to start playing. Therefore, we add a check in `Play()`, `CanActivateAutoplay()` to prevent media from playing. In addition, we should also prevent the audio channel agant from starting.
Differential Revision: https://phabricator.services.mozilla.com/D69672
--HG--
extra : moz-landing-system : lando
If docShell's `SuspendMediaWhenInactive` is true, then we should suspend or resume the media element according to the docshell active state when the docshell changes it active state.
Differential Revision: https://phabricator.services.mozilla.com/D69671
--HG--
extra : moz-landing-system : lando
Implemecurnt a flag `suspendMediaWhenInactive` on the docShell that indicates media in that shell should be suspended when the shell is inactive. Currently, only GeckoView is using this flag.
---
The reason of implementing this flag is because in bug1577890 we remove the old way to suspend/resume the media, and I thought setting docshell to inactive is enough to suspend the media because we already have a mechanism which would suspend/resume media when document becomes inactive/active [1].
However, the active state of document is actually different from what I thought it was. Setting docshell to inactive won't change the document's active state, because that indicates if the document is the current active document for the docshell [2] (docshell can have multiple documents), instead of indicating if the docshell is active or not.
Therefore, we have to add another flag to indicate if the docshell wants to suspend its media when it's inactive, in order to use current mechanism to suspend/resume media.
[1] https://searchfox.org/mozilla-central/rev/4d2a9d5dc8f0e65807ee66e2b04c64596c643b7a/dom/html/HTMLMediaElement.cpp#6453
[2] https://searchfox.org/mozilla-central/rev/4d2a9d5dc8f0e65807ee66e2b04c64596c643b7a/dom/base/Document.h#2627-2633
Differential Revision: https://phabricator.services.mozilla.com/D69669
--HG--
extra : moz-landing-system : lando
It seems that all the warnings caused by the GPU sandbox have been fixed, and
the transparent window issue was resolved in D61370.
Hopefully there are no further complications and this can stay landed.
Differential Revision: https://phabricator.services.mozilla.com/D18876
--HG--
extra : moz-landing-system : lando
We'll want some kind of backstop no matter what optimization algorithm we use.
We don't want to go too long without running any given task so we can find
regressions quickly and have a good merge candidate.
This pulls the logic that handles this out of the SETA strategy and into its
own strategy.
This will also make the SETA shadow scheduler more representative of what the
algorithm is doing.
Note in the future we may find ways to make this backstop more efficient (i.e
only run tasks that didn't run in the last 9 pushes for example).
Depends on D68621
Differential Revision: https://phabricator.services.mozilla.com/D68622
--HG--
extra : moz-landing-system : lando
This allows to nest strategies without having to register ever intermediate
composite strategy first. For example:
All(Any("skip-unless-schedules", "seta"), "backstop")
Prior to this patch, we'd need to register that 'Any' one first and then use it
in the 'All'.
Depends on D68620
Differential Revision: https://phabricator.services.mozilla.com/D68621
--HG--
extra : moz-landing-system : lando
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
Prior to this patch if we tried to extract extra data from an h264
sample but then found a partial NAL unit we'd discard the already found extra
data rather than processing it. This is problematic for avc3 streams where
encryption starts during a NAL unit, as even if we'd seen extra data prior to
finding such a partial unit, we'd discard it.
With this patch we will instead process the extra data we've already found in a
best effort attempt. If we get sent avc3 content that encrypts in band extra
data we'll still be in trouble, but I am not sure such content exists at this
stage.
This also changes our handling for non-encrypted streams, where we will now
also try to use any already discovered extra-data.
Differential Revision: https://phabricator.services.mozilla.com/D70767
--HG--
extra : moz-landing-system : lando
This undoes the changes from bug 1560092. These changes assumed that we couldn't
play encrypted avc3 content as we couldn't read SPS + PPS info from the stream.
However, after some testing I believe the issue is we can try and detect SPS +
PPS data in such streams, but need to better handle the encrypted case.
A following patch will address better handling SPS + PPS data in encrypted
streams.
Differential Revision: https://phabricator.services.mozilla.com/D70766
--HG--
extra : moz-landing-system : lando
Currently, with Fission enabled we are not able to create a proper LoadInfo
object when doing a subdocument load because we do not have access to a loading
context if the load is happening inside of an OOP frame. To solve this problem,
we can create LoadInfo object from scratch in the parent process where we have
all of the required information.
Differential Revision: https://phabricator.services.mozilla.com/D68893
--HG--
extra : moz-landing-system : lando
This fixes the content policy type for document loads in these frames, where
the explicit mIsFrame flag was not set, due to DocShell creation taking a
different code path in remote frames than in in-process frames.
Differential Revision: https://phabricator.services.mozilla.com/D52093
--HG--
extra : moz-landing-system : lando
The interpreter calls `TierUpTick` whenever we interpret a regexp. Once we hit the tick threshold, compileIfNecessary will compile native code for the regexp.
Currently the tick threshold is hard-coded to 10. V8's tick threshold is 1, which seems unreasonably low. We can tune this later.
Differential Revision: https://phabricator.services.mozilla.com/D70952
--HG--
extra : moz-landing-system : lando
The current ForceByteCodeEnum is a glorified boolean. This patch replaces it with a three-value bytecode/jitcode/either enum, which will make our tiering-up logic slightly nicer in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D70951
--HG--
extra : moz-landing-system : lando
Internally, irregexp uses -1 for errors, 0 for failure, and 1 for success. We have to use the same values in RegExpRunStatus.
Ideally we would replace RegExpRunStatus with an enum defined in RegExpTypes.h, but that will have to wait until we get rid of the old import.
Differential Revision: https://phabricator.services.mozilla.com/D70728
--HG--
extra : moz-landing-system : lando
The irregexp compiler takes the AST produced by the parser, compiles it down to a more efficient internal representation, then uses a 'macroassembler' to generate code. The generated code can either be bytecode (which is then fed into the interpreter) or jitcode (which can be executed directly).
This patch gets the infrastructure set up and handles the former case.
CompilePattern is based heavily on V8's `RegExpImpl::compile` (affc364620/src/regexp/regexp.cc (L745-L933)). I am upstreaming a patch to move the code in WrapBody into regexp-compiler.cc where it fits better.
V8 is about to land a patch to tweak the API for Interpret so that it allocates memory for its registers internally instead of requiring it to be passed in. When we import this change, we'll be able to pass `matches->pairsRaw()` directly into `MatchForCallFromRuntime`, and the interpreter will fill it in for us.
In the old engine, we could handle interrupts in the middle of the interpreter. If we hit an urgent interrupt in compiled code, we would generate bytecode and fall back to the interpreter (see https://searchfox.org/mozilla-central/rev/9120151ddb35f2d4c37bfe613a54a4f10a9a3dc5/js/src/vm/RegExpObject.cpp#1165-1175). (This is what all the `ForceByteCode` machinery in RegExpObject.cpp is about. It was added in bug 1077514.) That won't work in the new version. V8 does allow interrupts during regexp execution, but only by jumping through some scary hoops to "manually relocate unhandlified references" afterwards. Instead, we just retry the regexp. I have no idea what a reasonable number of retries is before giving up; I've arbitrarily picked 4 for now.
Differential Revision: https://phabricator.services.mozilla.com/D70695
--HG--
extra : moz-landing-system : lando
In preparation for actually compiling regexps in the next patch, hook up the V8 and irregexp representations of a compiled regexp.
Differential Revision: https://phabricator.services.mozilla.com/D70694
--HG--
extra : moz-landing-system : lando
A regexp with N sets of capturing parens will have N+1 capture groups, with the extra capture containing the entire matching string. Our old implementation stored `parenCount` in the RegExpShared and then added 1 to it whenever it was used. A much simpler answer is to just add 1 when initializing the regexp.
Differential Revision: https://phabricator.services.mozilla.com/D70693
--HG--
extra : moz-landing-system : lando
Unlinking, such as in UnbindFromTree, can add runnables that keep alive CCed
objects after they have been unlinked. In combination with some unknown
fields not being traversed and unlinked this could cause intermittent shutdown
leaks, if those unknown fields hold alive objects that need the CC to be
collected. Work around this by clearing out these runnables after every
shutdown CC.
Also, fix the order of these two steps, which was apparently wrong
before.
Differential Revision: https://phabricator.services.mozilla.com/D71049
--HG--
extra : moz-landing-system : lando
This patch prevents the addon-abuse-report-xulframe custom element from being defined
when AbuseReporter.openDialogDisabled is false (which is the default on all channels
starting from Firefox >= 73).
This change is also preventing the addon-abuse-report-xulframe custom element from
triggering an assertion failure in PresShell::ScrollContentIntoView, which seems to
be due to marionette calling browser.focus() while the custom element has just
injected the browser element that would contain the abuse report panel subframe.
This single-line patch is enough to prevent the assertion failure and still pass
all the existing tests. The addon-abuse-report-xulframe will be removed completely
as part of Bug 1614653.
Depends on D68805
Differential Revision: https://phabricator.services.mozilla.com/D71005
--HG--
extra : moz-landing-system : lando
The original document is at https://wiki.mozilla.org/AccessibleCaret. I
rewrite the in-tree version a bit, and will point the wiki version to
the in-tree version after this patch lands.
Differential Revision: https://phabricator.services.mozilla.com/D70477
--HG--
rename : layout/base/doc/AccessibleCaretEventHubStates.dot => layout/docs/AccessibleCaretEventHubStates.dot
rename : layout/base/doc/AccessibleCaretEventHubStates.png => layout/docs/AccessibleCaretEventHubStates.png
extra : moz-landing-system : lando
Because we now have layout/docs, it is confusion to keep layout/doc around.
Differential Revision: https://phabricator.services.mozilla.com/D70476
--HG--
extra : moz-landing-system : lando
- Remove function `Document::RemoveStyleSheet()`
- Remove function `ShadowRoot::RemoveSheet()`
- Remove function `DocumentOrShadowRoot::RemoveSheet()`, which was used by the former two functions.
- Add function `DocumentOrShadowRoot::RemoveStyleSheet()`, now uesed in all cases.
Differential Revision: https://phabricator.services.mozilla.com/D70927
--HG--
extra : moz-landing-system : lando
This is in anticipation of having a looser condition for enabling
DComp. Until that code is ready we might as well get more testing.
Differential Revision: https://phabricator.services.mozilla.com/D71060
--HG--
extra : moz-landing-system : lando
