These will be expiring - they're still relevant though, given recent
work on the startup cache and continued interest in startup perf.
Differential Revision: https://phabricator.services.mozilla.com/D51499
--HG--
extra : moz-landing-system : lando
OS_RGBA and OS_RGBX are defined as the preferred surface format for the
platform and architecture, fixed at compile time. Today this will be
initially defined as B8G8R8A8. The future intent is that once all parts
of the system support all configurations, then we can use R8G8B8A8 on
certain platforms (e.g. Android, Linux, Mac) and invert it on big-endian
architectures.
Differential Revision: https://phabricator.services.mozilla.com/D52006
--HG--
extra : moz-landing-system : lando
Seems less gnarly than the alternatives, and we'd only free it until shutdown so
not much worse, actually.
Differential Revision: https://phabricator.services.mozilla.com/D51871
--HG--
extra : moz-landing-system : lando
The existing code wasn't sound, as CSSOM objects also needed to go away before
the shared memory goes away (as they keep references to them).
This is sound assuming no presence of reference cycles introduced by CSSOM.
We may want to live with this and rely on chrome code not writing cycles like
this with UA stylesheet DOM objects.
We could explicitly drop all potentially-static objects... That seems pretty
error prone though.
Or we could also just leak the shared memory buffer, is there any reason why we
may not want to do that?
Differential Revision: https://phabricator.services.mozilla.com/D51870
--HG--
extra : moz-landing-system : lando
This test was created for the initial version of blocking autoplay, where the user activation flag would only be propagated to the same origin frames among the frames tree. It was rewritten once we changed the way of propagating the user activation flag, where we would always propagate the flag from child to parent. Once the parent has been activated, all children frames would be allowed to autoplay.
However, this test has a lots of overlaps with the `test_autoplay_policy_activation.html`, which also test blocking autoplay in the form of a parent and a child frame.
The only two parts, which aren't covered in that test, are (1) activating child frame could also activate parent frame (it's added in patch5) (2) testing more than 2 hierarchies frames, but it's not necessary, because what we care is whether the frame is cross-origin or not, no matter how many hierarchies we have. So the 2 hierarchies tests in `test_autoplay_policy_activation.html` should be enough.
Differential Revision: https://phabricator.services.mozilla.com/D51720
--HG--
extra : moz-landing-system : lando
Increase test cases of activating child frame would also activate its parent frame, no matter the child frame is cross-origin or not.
Differential Revision: https://phabricator.services.mozilla.com/D51691
--HG--
extra : moz-landing-system : lando
In order to reduce the parameters count we send to functions, which can improve readability, we wrap all testing related information to `testInfo`, so that we only need to pass it among different functions.
Differential Revision: https://phabricator.services.mozilla.com/D51687
--HG--
extra : moz-landing-system : lando
In order to create the flexibility of test cases, I separate the creation of iframe and starting media from iframe, and use `play_from` to indicate which frame is the autoplay starts from.
That allows us to to create a test case which contains an iframe but the media is actually played from the parent frame.
Differential Revision: https://phabricator.services.mozilla.com/D51686
--HG--
extra : moz-landing-system : lando
Currently the logic for process selection extracts a URI from the principal, and
uses that URI to perform process selection. This patch adds a codepath for
passing the result principal through the remote type selection logic and using
it directly.
This should ideally improve the behaviour of URIs with less obvious origins,
such as those which inherit their origin.
Unfortunately, OriginAttributes are still ignored by process selection, due to
some code using the fallback logic which is unaware of OAs. This should be fixed
in the future.
Differential Revision: https://phabricator.services.mozilla.com/D51942
--HG--
extra : moz-landing-system : lando
Most of these tests relied on assumptions that were broken by the new content
event utils (timing, being in a ContentTask, etc).
Differential Revision: https://phabricator.services.mozilla.com/D51442
--HG--
extra : moz-landing-system : lando
This also changes BrowserTestUtils.addContentEventListener to use browsing
contexts to track added listeners and their associated targets.
Differential Revision: https://phabricator.services.mozilla.com/D51441
--HG--
extra : moz-landing-system : lando
Various BrowserTestUtils.waitForContentEvent call sites expect to see an event
on a browser element that was open before the call was made. For this reason,
each of the browsers need to also have a ContentEventListener actor.
Differential Revision: https://phabricator.services.mozilla.com/D51440
--HG--
extra : moz-landing-system : lando
BrowserTestUtils.waitForErrorPage may resolve slightly earlier than it did
before, so we may arrive at an about:neterror page that hasn't been completely
initialized. We should only dispatch the AboutNetErrorLoad event when we're done
making changes to the page.
Differential Revision: https://phabricator.services.mozilla.com/D51439
--HG--
extra : moz-landing-system : lando
Exposes a new nsIDocShell API, isForceReloading, to determine if
the loaded document was force-reloaded or not.
It relies on the underlying behaviour of nsDocShell::IsForceReloading(),
which again relies on nsDocShell::IsForceReloadType(mLoadType).
The getter is used in the remote agent to test that
Page.reload({ignoreCache: true}) works as intended.
Differential Revision: https://phabricator.services.mozilla.com/D51435
--HG--
extra : moz-landing-system : lando
This change updates the home page to webxr.today for Firefox Realty on Desktop. Further, since WebVR is not supported yet, this change includes a way to disable WebVR specifically for FxR windows without impacting Desktop Fx.
Differential Revision: https://phabricator.services.mozilla.com/D51426
--HG--
extra : moz-landing-system : lando
Remove moz_container_get_scale() and use only nsWindow::GdkScaleFactor() to get scale factor for wl_surface and wl_egl_window.
Always set the scale factor when wl_surface / wl_egl_window is queued for rendering.
Differential Revision: https://phabricator.services.mozilla.com/D51252
--HG--
extra : moz-landing-system : lando
The probe was added to metrics.yaml in bug 1584109. Its corresponding
probe in Histograms.json was renamed from WR_RENDER_TIME to
WR_FRAMEBUILD_TIME to better describe what it is measuring. But the
rename in metrics.yaml was accidentally lost during a rebase, and it
was landed it as render_time. This renames it to framebuild_time, as
was intended.
Differential Revision: https://phabricator.services.mozilla.com/D51995
--HG--
extra : moz-landing-system : lando
This is especially important for media elements playing MediaStreams, since the
streams can be manipulated to end playback of the elements synchronously by
either stopping or removing their tracks.
Differential Revision: https://phabricator.services.mozilla.com/D49385
--HG--
extra : moz-landing-system : lando
This adds four test cases:
- HTMLVideoElement playing a video track, ending through the track ending.
- HTMLAudioElement playing an audio and a video track, ending through the audio
track ending.
- HTMLVideoElement playing a video track, ending through the track being
removed.
- HTMLAudioElement playing an audio track and a video track, ending through the
audio track being removed.
All test cases test the timing of when the HTMLMediaElement starts reporting
true for its ended attribute, and the timing of the ended event.
Differential Revision: https://phabricator.services.mozilla.com/D49384
--HG--
extra : moz-landing-system : lando
This swaps things around so that received tracks in peer connections have a
content principal instead of a null principal initially.
This puts an extra requirement on us to not output any frames under the content
principal after ALPN has been negotiated with requested privacy, but before this
private principal has been signaled to the MediaPipelines. The private principal
is signaled from the STS thread, via the main thread, whereas media is consumed
directly by MediaPipelines after being received on the STS thread.
This patch adds an extra signaling path directly from the STS thread that tells
MediaPipelines to make their PrincipalHandle private, and to ignore any data
until the private PrincipalHandle is set. It also moves the responsibility of
updating the principal of the received MediaStreamTracks from TransceiverImpl
to MediaPipeline, so it's all in the same path.
This lets all MediaStream and MediaStreamTrack APIs consume received tracks
directly after getting exposed to JS without errors. In case privacy is later
requested, consumers that have already been set up must handle this on the fly.
(They do, in specs and impls)
Differential Revision: https://phabricator.services.mozilla.com/D48947
--HG--
extra : moz-landing-system : lando
nsISerialEventTarget is more semantically accurate for these uses, as the
dispatched runnables cannot run in parallel. It also allows us to use
InvokeAsync in future patches, as that function only takes nsISerialEventTarget.
Differential Revision: https://phabricator.services.mozilla.com/D49262
--HG--
extra : moz-landing-system : lando
