Unfortunately, this change makes content process and chrome process doesn't go
through the same code path because nsFocusManager handles their state
separately on purpose.
Differential Revision: https://phabricator.services.mozilla.com/D90033
Currently there is a "benign" race between background sweeping and gray
unmarking. The latter does not affect the result of the former, but any data
race is undefined behaviour.
This patch changes the marking bitsmaps to be relaxed atomic to avoid this.
Marking bitmaps were already excluded from TSAN checks.
Differential Revision: https://phabricator.services.mozilla.com/D90239
Likely happens mostly in automation. At least Thunderbird have places where the view is going to be replaced and the selection is cleared first.
Differential Revision: https://phabricator.services.mozilla.com/D90253
This is causes taking back bugs in
`WSRunScanner::GetNewInvisibleLeadingWhiteSpaceRangeIfSplittingAt()` and
`WSRunScanner::GetNewInvisibleTrailingWhiteSpaceRangeIfSplittingAt()` (I.e.,
they were fixed by bug 1647556). Therefore, this removes the odd `if` blocks
which are pointed with `XXX` comment for avoiding "regressions" (without them,
some WPTs for `InputEvents.getTargetRanges()` become failure).
Depends on D89582
Differential Revision: https://phabricator.services.mozilla.com/D89869
To make sure we're testing recursive inlining, I've tweaked the thresholds to ensure that we can inline two levels deep without any loops. I've also made the inlining heuristics slightly more conservative, which prevents `check-earley-boyer` from timing out.
I've also included a few drive-by fixes. The change to `isRecursive` in `DoTrialInlining` only affects the jitspew message, because both ways of finding the `InliningRoot` are equivalent for the non-recursive case.
Differential Revision: https://phabricator.services.mozilla.com/D89875
AFAICT, outside of the bytecode generator, there is no longer any difference between `JSOp::Super` and `JSOp::New` except for the expression decompiler.
Differential Revision: https://phabricator.services.mozilla.com/D89874
We already did the hard work to handle `this` creation for transpiling, so inlining is pretty straight-forward.
`patchInlinedReturn` needs to know whether we're calling a derived constructor to avoid repeated bailouts in `MReturnFromCtor`. I used a similar solution to what anba did here: https://phabricator.services.mozilla.com/D58785). Once Ion is gone, we could consider modifying `MReturnFromCtor` instead.
Differential Revision: https://phabricator.services.mozilla.com/D89873
Instead of storing a flag in GuardSpecificFunction, I reused the CallFlags that are already being stored in the call. This also lets us avoid a VM call in the baseline IC.
After Ion is gone, we can consider storing a ConstructorKind in CallFlags (with values `None`, `UninitializedThis`, `Template`, and `VMCall`) and moving the template object offset from `MetaTwoByte` into `CallScriptedFunction`.
Differential Revision: https://phabricator.services.mozilla.com/D89872
Before bug 1660557, this was actually clearing an old migration pref, but now
it's clearing the actual theme pref used by Sync.
Differential Revision: https://phabricator.services.mozilla.com/D90194
In order for Thunderbird to effectively cut down on excess builds, there needs
to be a way to define taskgraph optimization strategies beyond what is made
available in the mozilla repository.
taskgraph.optimize.register_strategy gets half of the job done. The other piece
is task schema validation which checks optimizations against OptimizationSchema.
OptimizationSchema gets moved to taskgraph.optimize.schema so that it is not set
too early by taskgraph.util.schema. Projects then call set_optimization_schema()
to replace the default schema object. set_optimization_schema() needs to be called
in the project's taskgraph:register function before any transform code is loaded.
Differential Revision: https://phabricator.services.mozilla.com/D88429
By passing the content viewer to CreateStaticClone we can do this fairly
easily. I'm going to add another entry-point to the clone process and
it'd be good if we avoid repeating the SetDocument dance and so on.
Differential Revision: https://phabricator.services.mozilla.com/D90315