For Fission, the parent process needs to take an Accessible sent up from one content process and send it down to another content process, where it will eventually be returned to the client.
If sandboxing is enabled, we must use a PassthruProxy, and if the handler is enabled, the handler will marshal the interface.
Even though we strip out the handler, the handler still marshals using the aggregated standard marshaler, which uses a different clsid (CLSID_AggStdMarshal).
When unmarshaling to return to the client, we call GetObjRefSize.
This previously didn't know about the aggregated standard marshaler, so it failed, causing E_INVALIDARG to be returned to the client.
Now, we just handle these clsids in the same way.
Differential Revision: https://phabricator.services.mozilla.com/D51246
--HG--
extra : moz-landing-system : lando
With the recent changes to compositing in WR, the scene must either
only produce produce cache tiles, or disable picture caching and
rasterize directly.
This patch removes the (currently broken) path where WR would attempt
to disable only the picture cache slice(s) that have a complex
transform.
In future, we should disable creating picture cache slices with
complex transforms at the API level, and remove this path completely.
Differential Revision: https://phabricator.services.mozilla.com/D51228
--HG--
extra : moz-landing-system : lando
The buffer range starts at 1 (the first valid entry, 0 is reserved as
null marker). So if it now starts *after* 1, it means we have started to
overwrite our oldest data, and we should get rid of Base profiles if any.
Differential Revision: https://phabricator.services.mozilla.com/D51225
--HG--
extra : moz-landing-system : lando
This allows the bytecode emitter to vary its code paths depending on whether
or not we are deferring GC object allocation.
Depends on D51010
Differential Revision: https://phabricator.services.mozilla.com/D51011
--HG--
extra : moz-landing-system : lando
This is subsequently used to allow BytecodeEmitter access to the ParseInfo,
so that the BytecodeEmitter can decide the vary its behviour depending on
the ParseInfo.
Differential Revision: https://phabricator.services.mozilla.com/D51010
--HG--
extra : moz-landing-system : lando
When the `Debugger` API sets a breakpoint in a JSScript or wasm::Instance, the
BreakpointSite and Breakpoint objects belong to the code's compartment
(logically, at least - they're C++ objects and don't actually have any
compartment). Since a `Debugger` and its debuggees must be in separate
compartments, the Breakpoint's references to its owning `Debugger` and its
handler object must go through cross-compartment wrappers.
If we have nuked the `Debugger`'s compartment, it's not clear how we're still
trying to set breakpoints in its debuggees, but we should at least throw an
error, to capture a JavaScript stack when it occurs.
Differential Revision: https://phabricator.services.mozilla.com/D51210
--HG--
extra : moz-landing-system : lando
Setting a hook on a `Debugger` may expand the set of behaviors it observes, so
that new scripts and stack frames must have their `isDebuggee` flags set. The
`Debugger::updateExecutionObservabilityOfFrames` function is supposed to walk
the stack and sets the flag where necessary.
However, the old code performed that stack walk using `FrameIter`, which follows
'debugger eval prev` links, potentially skipping over stack frames that need to
be flagged. This patch changes the code to use `AllFramesIter`, which differs
from `FrameIter` only in that it ignores 'debugger eval prev' links.
Differential Revision: https://phabricator.services.mozilla.com/D47148
--HG--
extra : moz-landing-system : lando
This is more or less restricted to using `Span::data` and `Span::size` instead
of the equivalent counterparts from `Range`. For example span iterators aren't
used in non-debug code, because the generated code when using span iterators is
ridiculously large.
Differential Revision: https://phabricator.services.mozilla.com/D51122
--HG--
extra : moz-landing-system : lando
Two minor changes for slightly improved generated assembly:
- Use addition/subtraction in AsciiTo[Upper,Lower]Case to ensure the compiler
emits `lea` instead of `mov + bitop`.
- Avoid dead SIMD code generation in LanguageTagSubtag case conversion methods.
Differential Revision: https://phabricator.services.mozilla.com/D51120
--HG--
extra : moz-landing-system : lando
Similar to the previous parts, case normalisation for language, script, and
region subtags now happen as part of the canonicalisation process.
`LanguageTagParser::internalParseBaseName()` no longer needs to differentiate
between parsing a normal base name or a base name within a transform extension,
therefore we can remove its `BaseNameParsing` argument.
The three `ParseStandalone` functions can now use the shared `IsStructurallyValid`
functions, reducing duplicate code.
Subtag canonicalisation in LanguageTagGenerated.cpp now needs to check for case
normalised tags, so some additional assertions were added.
Differential Revision: https://phabricator.services.mozilla.com/D51119
--HG--
extra : moz-landing-system : lando
Moves the case normalisation for variant subtags out of the language tag parser
and into the canonicalisation method. Additionally duplicate variants are now
checked after all variant subtags have been case normalised and sorted, which
makes the duplicate variant check O(n) instead of O(n²). In our implementation
we're always canonicalising language tags directly after parsing them, so
there's no user observable difference when duplicate variants are checked.
Differential Revision: https://phabricator.services.mozilla.com/D51118
--HG--
extra : moz-landing-system : lando
Case normalisation for extension and private-use subtags now happens in `LanguageTag::canonicalizeExtensions`.
The `IsStructurallyValid` functions were updated to only test for structural validity, now finally
matching their name. And `LanguageTagParser::extension(...)` was inlined, because it no longer
also needs to perform case normalisation, which makes it small enough for an inline function.
Differential Revision: https://phabricator.services.mozilla.com/D51117
--HG--
extra : moz-landing-system : lando
`unicodeExtensionIndex()` is already checking for 'U' in preparation for part 2.
Differential Revision: https://phabricator.services.mozilla.com/D51115
--HG--
extra : moz-landing-system : lando
The estimated memory is based on the maximum observed memory usage when running
the Java script attached to the bug report.
Differential Revision: https://phabricator.services.mozilla.com/D51087
--HG--
extra : moz-landing-system : lando
This also updates the canToggle=false code paths in the Picture-in-Picture
mochitest head.js file, which were obviously never really exercised until
now.
Differential Revision: https://phabricator.services.mozilla.com/D51160
--HG--
extra : moz-landing-system : lando
This patch adds GPU and CPU clock frequencies as well as Watts used to the metrics that are gathered into perfherder from mozpower.
Differential Revision: https://phabricator.services.mozilla.com/D50522
--HG--
extra : moz-landing-system : lando
Other places take care to handle this case, but not running the tooltool
script. Let's fix that.
Differential Revision: https://phabricator.services.mozilla.com/D51266
--HG--
extra : moz-landing-system : lando
This makes HeapPtr members const where it was easy to do so. Flagging jimb for review since most of these were in the debugger.
Differential Revision: https://phabricator.services.mozilla.com/D50624
--HG--
extra : moz-landing-system : lando
Geoff Brown
Steve Fink
James Teh
Morgan Reschenberg
Luca Greco
Jonathan Kew
Glenn Watson
Gerald Squelart
Matthew Gaudet
Narcis Beleuzu
Gabriele Svelto
Jim Blandy
Junior Hsu
Marco Bonardo
Itiel
André Bargull
Lee Salzman
Mike Conley
Dan Minor
Jorg K
Gregory Mierzwinski
Cosmin Sabou
Alexander J. Vincent
Ricky Stewart
Alessio Placitelli
Jason Laster
Erica Wright
ffxbld
Nathan Froyd
Mark Banner
Henrik Skupin
Jon Coppeard