This implements the idea of automatically setting a content proc's
render root based on the render root enclosing the iframe that
points to it. There was a bit of cleanup in here that was a bit
tricky to extract from the core patch revolving around how we
use the Api(...) helper. This was to avoid the situation where
we use the Api(...) helper before our render root is initialized,
when we don't actually have to. I.e., when we just want the root
WebRenderAPI in all cases.
An alternative to this approach could be to fully built out the
WebRender transactions and just queue those up to be sent. However,
transaction building has various side effects which are committed
before the transaction is actually sent, so we would have to build
out some scheme for deferring those as well. This seemed simpler.
Patch primarily written by :dthayer
Differential Revision: https://phabricator.services.mozilla.com/D37078
--HG--
extra : moz-landing-system : lando
This splits out the inner bit of RecvEmptyTransaction to just iterate over
the documents once, rather than iterating over them individually. Originally
I ran into difficulties with this and then left it on the table, but I think
it was enabled by splitting out the epochs in pipeline info by renderroot.
Differential Revision: https://phabricator.services.mozilla.com/D35123
--HG--
extra : moz-landing-system : lando
The tool tip for a browser tab exposes information such as the process ids (on Nightly) and the container tab name.
It appears when a user mouses over the tab, but this isn't really accessible to screen reader users.
Ideally, we'd expose this information as the accessible description for all browser tabs.
However, doing this for all tabs and keeping it up to date is rather difficult and potentially expensive.
Instead, just expose this description for a tab when it gets focus; i.e. the user has to focus the tab bar to access it.
To enable this, XUL tab elements now fire an AriaFocus event on the ARIA focused tab when the ariaFocusedItem property is set.
Differential Revision: https://phabricator.services.mozilla.com/D38027
--HG--
extra : moz-landing-system : lando
This has equivalent overall behavior as before, but computes the
precise LazyScript::TreatAsRunOnce flag rather than checking the extra
conditions during delazification. The heuristics can be computed using
just the LazyScript information so the result is the same.
Differential Revision: https://phabricator.services.mozilla.com/D38025
--HG--
extra : moz-landing-system : lando
Decouple the JSScript creation for delazification from needing
CompileOptions. When JSScript and LazyScript become unified, this
operation will become a no-op.
Differential Revision: https://phabricator.services.mozilla.com/D38023
--HG--
extra : moz-landing-system : lando
With the current design of ImmutableScriptData, even empty arrays have a
legal span so we no longer need to change the hasTryNotes and friends
helpers. In most cases we were performing a range-for afterwards so this
has simpler semantics.
Differential Revision: https://phabricator.services.mozilla.com/D37882
--HG--
extra : moz-landing-system : lando
This is a partial revert of bug 1524890 - P17.
When setting the duration, with some videos, on output WMF set nonsensical values. Sometimes the duration read is equal to the timestamp of the previous frame leading to broken A/V sync.
In bug 1222874, we will remove the entire concept of video frame's duration.
Differential Revision: https://phabricator.services.mozilla.com/D37683
--HG--
extra : moz-landing-system : lando
This change replaces and removes code in VRManager that was refactored into the
new VRShMem class.
Differential Revision: https://phabricator.services.mozilla.com/D36986
--HG--
extra : moz-landing-system : lando
This reduces a bit of code complexity, fixes bugs where we weren't
reflowing enough, and optimizes additional cases that we couldn't
optimize in the past.
Co-authored-by: Chris Pearce <cpearce@mozilla.com>
Co-authored-by: L. David Baron <dbaron@dbaron.org>
Differential Revision: https://phabricator.services.mozilla.com/D37610
--HG--
extra : moz-landing-system : lando
Co-authored-by: L. David Baron <dbaron@dbaron.org>
Co-authored-by: Chris Pearce <cpearce@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D37609
--HG--
extra : moz-landing-system : lando
Currently items are painted with a context that has a transform of
-mLayerBounds.TopLeft(). This means that if TopLeft() changes the commands
will be in the wrong place because the -TopLeft() offset is baked into the
recording.
I don't think we've ever needed to support painting without this transformed
baked in so there were some infrastructure changes that needed to be made to
make this possible. Most of the problems come from the use of
gfxContext::GetClipExtents which expose the bounds of the underlying surface.
The biggest of these was fixed by the CreateClippedDrawTarget rewrite. The rest
should be handled by ensuring that the DrawTarget has bounds that are at least
as big as the union of the individual item bounds. i.e. GetClipExtents should
never intersect with bounds of the item.
This change has a couple of parts:
1. Store mLayerBounds.TopLeft() in the recording so that it will be subtracted
during replay
2. Use mLayerBounds as the Rect of the RecordingDrawTarget
3. Don't include mLayerBounds.TopLeft() in the transform during recording.
4. Adjust the dirty rect by recordingOrigin before we use it as a clip so that
it stays in the right place.
5. In PaintContainerItem the bounds parameter of PushLayer is in device space
so we need to account for the shift in the location of device space in the
DrawTargetRecording.
Differential Revision: https://phabricator.services.mozilla.com/D37513
--HG--
extra : moz-landing-system : lando
