It must be possible to retrieve any accessible by calling IAccessible::accChild on the RootAccessible (in the parent process) with the unique id of the desired accessible.
Among other things, this is the way accessibility events are targeted on Windows.
Previously, this code only searched remote documents at the top level of the tree.
In order to support out-of-process iframes, it must now also search embedded documents at the top level of their content process.
As part of this, the MSAA id must be set for out-of-process iframe documents, just as it is for top level documents.
This was already being sent from the content process, but previously, we didn't store this in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D32417
--HG--
extra : moz-landing-system : lando
Aside from the parent being needed by the client, this is also important because events from the embedded document are deferred until the parent COM proxy is received.
Differential Revision: https://phabricator.services.mozilla.com/D32284
--HG--
extra : moz-landing-system : lando
Previously, a COM proxy was only sent from content for top level documents.
Now, a COM proxy is also sent (and needed) for out-of-process iframe documents.
This change adjusts GetProxiedAccessibleInSubtree accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D32283
--HG--
extra : moz-landing-system : lando
DocAccessibleParent already has IsTopLevel(), which identifies a document at the top level of the hierarchy; i.e. it has no parents.
Now that we have out-of-process iframes, we need to be able to identify and retrieve documents at the top level of their content process, even if they are embedded by another remote document.
DocAccessibleParent::IsTopLevelInContentProcess() has been introduced to achieve this.
BrowserParent::GetTopLevelDocAccessible() now uses this instead of IsTopLevel(), since we want to be able to get the top DocAccessibleParent even for a BrowserParent for an out-of-process iframe.
Differential Revision: https://phabricator.services.mozilla.com/D32282
--HG--
extra : moz-landing-system : lando
Also rename decommitAllArenasWithoutUnlocking to make it clear that it does
not do what decommitAllArenas does, since it only decommits free arenas.
Differential Revision: https://phabricator.services.mozilla.com/D33108
--HG--
extra : moz-landing-system : lando
Invoking MozbuildObject.substs causes an exception to be raised if there is no
BuildEnvironment. This means that we hit an error on |mach help| if there is no
build, which is not ideal for people trying to learn how to build :).
Differential Revision: https://phabricator.services.mozilla.com/D33217
--HG--
extra : moz-landing-system : lando
Now that we have a suitable composition recorder infrastructure, it is just a
matter of plumbing the `WebRenderCompositionRecorder` from the
`CompositorBridgeParent` to the `RenderThread` to start recording frames.
Differential Revision: https://phabricator.services.mozilla.com/D32234
--HG--
extra : moz-landing-system : lando
Since WebRender does its rendering on a separate thread from the compositor
thread, we need a composition recorder that can be shared between threads.
Differential Revision: https://phabricator.services.mozilla.com/D32231
--HG--
extra : moz-landing-system : lando
The AsyncScreenshotGrabber now can operate in two modes:
* `ProfilerScreenshots`, which does asynchronous scaling of the captured frames
for inclusion in profiles by the Gecko Profiler; and
* `CompositionRecorder`, which does not do any scaling and is used for visual
metrics computations.
The latter mode is exposed by on the `Renderer` via the `record_frame`,
`map_recorded_frame`, and `release_composition_recorder_structures` methods.
A different handle type (`RecordedFrameHandle`) is returned and consumed by
these functions, but they translate between `RecordedFrameHandle` and
`AsyncScreenshotHandle` when communicating with the underlying
`AsyncScreenshotGrabber`.
I considered making the `AsyncScreenshotGrabber` generic over its handle type,
but the extra cost of monomorphization just to change the handle type did not
seem worth it.
Differential Revision: https://phabricator.services.mozilla.com/D32232
--HG--
extra : moz-landing-system : lando
The CompositionRecorder was being stored as a UniquePtr on the
CompositorBridgeParent, but was then passed to and stored on the LayerManger as
a raw pointer. This has been updated to use a RefPtr.
Differential Revision: https://phabricator.services.mozilla.com/D32230
--HG--
extra : moz-landing-system : lando
The `WebProgressChild` no longer sends a `matchedList` parameter in its JSON
messages to the `RemoteWebProgress`, so it will always be undefined and trigger
a `ReferenceError`.
Differential Revision: https://phabricator.services.mozilla.com/D33202
--HG--
extra : moz-landing-system : lando
The WebRenderBridgeChild now records whether or not it was painting content
while sending display lists to the WebRenderBridgeParent, allowing for
composition times to be recorded for WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D32229
--HG--
extra : moz-landing-system : lando
Now that we have a suitable composition recorder infrastructure, it is just a
matter of plumbing the `WebRenderCompositionRecorder` from the
`CompositorBridgeParent` to the `RenderThread` to start recording frames.
Differential Revision: https://phabricator.services.mozilla.com/D32234
--HG--
extra : moz-landing-system : lando
Since WebRender does its rendering on a separate thread from the compositor
thread, we need a composition recorder that can be shared between threads.
Differential Revision: https://phabricator.services.mozilla.com/D32231
--HG--
extra : moz-landing-system : lando
The AsyncScreenshotGrabber now can operate in two modes:
* `ProfilerScreenshots`, which does asynchronous scaling of the captured frames
for inclusion in profiles by the Gecko Profiler; and
* `CompositionRecorder`, which does not do any scaling and is used for visual
metrics computations.
The latter mode is exposed by on the `Renderer` via the `record_frame`,
`map_recorded_frame`, and `release_composition_recorder_structures` methods.
A different handle type (`RecordedFrameHandle`) is returned and consumed by
these functions, but they translate between `RecordedFrameHandle` and
`AsyncScreenshotHandle` when communicating with the underlying
`AsyncScreenshotGrabber`.
I considered making the `AsyncScreenshotGrabber` generic over its handle type,
but the extra cost of monomorphization just to change the handle type did not
seem worth it.
Differential Revision: https://phabricator.services.mozilla.com/D32232
--HG--
extra : moz-landing-system : lando
The CompositionRecorder was being stored as a UniquePtr on the
CompositorBridgeParent, but was then passed to and stored on the LayerManger as
a raw pointer. This has been updated to use a RefPtr.
Differential Revision: https://phabricator.services.mozilla.com/D32230
--HG--
extra : moz-landing-system : lando
Previously the end of JumpList's link is marked by `offset + delta == -1`,
BytecodeOffset class introcuced in part 3 requires the operands of `-` operator
should be valid, and that rule conflicts with above.
Changed the end marker of JumpList to `delta == 0`, that won't happen in other
case, because that points the same opcode.
Differential Revision: https://phabricator.services.mozilla.com/D33053
--HG--
extra : moz-landing-system : lando
Previously the initial value of BytecodeSection.lastTarget_ is chosen to make
the following condition true:
lastTargetOffset() + ptrdiff_t(JSOP_JUMPTARGET_LENGTH) == -1
BytecodeOffset class introcuced in part 3 requires the offset value to be
either -1 (invalid) or non-negative, and that rule conflicts with above.
Changed the initial value of BytecodeSection.lastTarget_ to -1 and added
the check for that condition in BytecodeSection::lastOpcodeIsJumpTarget,
so that we don't use negative value in BytecodeOffset.
Differential Revision: https://phabricator.services.mozilla.com/D33052
--HG--
extra : moz-landing-system : lando
Classes defined in JS using the `class` keyword, without using `extends`,
implicitly construct a new `this` object before running the body of the
constructor, and they use `new.target.prototype` as the new object's
[[Prototype]]. This is one of the ways that JS classes support subclassing.
When the subclass calls the base class constructor, the subclass's `.prototype`
is used.
Until now, we did not do this for classes defined in C++ using
JS_NewObjectForConstructor. But there's no reason it shouldn't work the same
way. Changing this is a nicety for embedders -- there's nothing using it in
Firefox or internally right now, except for testing.
Differential Revision: https://phabricator.services.mozilla.com/D31490
--HG--
extra : moz-landing-system : lando
Mike Conley
James Teh
Paul Bone
Andrew Halberstadt
Barret Rennie
Ting-Yu Lin
Tom Prince
Coroiu Cristina
Steve Fink
Rob Wood
Tooru Fujisawa
Connor Brewster
Noemi Erli
Jason Orendorff