The experiment has served its purpose, gathering 66k+ telemetry events and showing no negative impact to connection result.
DC is now enabled by default in Nightly, so we no longer need to run this study.
Differential Revision: https://phabricator.services.mozilla.com/D72699
Other UAs allow this, and it seems in the general consensus of
https://github.com/w3c/webcomponents/issues/179.
This matches WebKit's behavior. Blink, for some reason shows red on the
test-case, probably because they're not doing quite this, but they
manage to render masks inside the display: none symbol element or such.
Differential Revision: https://phabricator.services.mozilla.com/D72610
This change will permit the `TestResolver` to add web-platform-tests into the list of supported tests.
Changes:
- add web-platform-test test objects to the list of supported tests.
- adjust value of attributes name, manifest, manifest_relpath.
Differential Revision: https://phabricator.services.mozilla.com/D70727
The retry on download complete did not work properly, and we trust
the size of the file given that we download over https and check
with CertCheck, so I removed the other size checks which would have
retried infinitely given issues.
Differential Revision: https://phabricator.services.mozilla.com/D72746
It complicates all the ID tracking code and the SVG code quite a bit.
I want to know if it is used so that we can maybe remove it.
Differential Revision: https://phabricator.services.mozilla.com/D72613
The original workaround given by Microsoft was both WS_EX_TRANSPARENT and WS_EX_LAYERED. In bug 1627505 we tried to just add WS_EX_LAYERED because it was all that was needed to fix that bug and we hoped it wouldn't re-introduce the blank window problem. But it did. So we may as well go with both flags as recommended by Microsoft.
Differential Revision: https://phabricator.services.mozilla.com/D72598
ExtensionPolicyService::CheckContentScripts does retrieve mContentScripts a WebExtensionPolicy instance
and it may call the ExtensionProcessScript methods PreloadContentScript or LoadContentScript while iterating
over it mContentScript.
Both PreloadContentScript and LoadContentScript are going to run some privileged JS code, and LoadContentScript
will load an extension content script. There is a chance that some of the JS code executed could call
WebExtensionPolicy::UnregisterContentScript (or RegisterContentScript) and mutate the mContentScripts array
that EPS::CheckContentScripts is already iterating over, and when that happens it is possible that once the
execution goes back to the ongoing CheckContentScripts iteration, the iterator is invalidated and
the InvalidArrayIndex_CRASH triggered.
Differential Revision: https://phabricator.services.mozilla.com/D69336
It's meant to double-check we're stable and so on, but sometimes the
browser UI decides to override the zoom with the default zoom which
would break the assertion.
I'll look into that separately.
Differential Revision: https://phabricator.services.mozilla.com/D72706
As there is no way that the method can return true, we might as well skip the
work of constructing URIs. This also avoids unnecessary errors when trying to
do so for chrome URIs that are not valid, like the ones produced by FxA.
Differential Revision: https://phabricator.services.mozilla.com/D72556
The RenderBackend can be sent an `invalidate_rendered_frame` flag to
indicate that the current rendered frame is invalid. This is useful
when the platform requires a render, eg when starting or resuming the
app on Android. Upon receiving this flag, the render backend will set
a variable `doc.rendered_frame_is_valid = false`. Later on it will
decide to skip rendering only if this variable is true, so by setting
the invalidate flag we should be able to ensure the next render will
occur.
However, the RenderBackend also tries to skip renders which it
determines are not required. Currently it does this by setting
`doc.rendered_frame_is_valid = true` if it decides the frame is a
no-op. This overwrites the previous value set by the
`invalidate_rendered_frame` flag, meaning webrender skips renderering
even though the platform has requested it.
This was resulting in the GVE app showing a black screen on startup,
and Fenix temporarily showing a black screen whilst opening a new tab,
because despite WebRenderBridgeParent requesting an invalidation
immediately on startup, webrender ignored that request until it
decided it actually had content to paint.
To fix this, the logic should be flipped. The value of
`doc.rendered_frame_is_valid` must be remembered across document
updates rather than defaulting to false. And instead of setting it
true if webrender thinks the frame is a no-op, we must set it false if
webrender thinks the frame is *not* a no-op.
Differential Revision: https://phabricator.services.mozilla.com/D72600
Both the deprecated `Screen.lockOrientation` and replacement
`ScreenOrientation.lock` APIs have been updated to make use of a new
`OrientationLock` field on the `BrowsingContext`. This replaces the
storage and use of APIs for this on the root docshell.
In the non fission case things should behave the same, as pending
promises for previous calls to `Screen.lockOrientation` will still be
cancelled in process. If there are `BrowsingContext`s in other
processes though, IPC will be sent to the parent, and then each other
child to cancel them. This should be spec compliant as the spec is
already racy with regards to multiple `lockOrientation` calls.
This new implementation has a little extra IPC than the optimal
implementation would since the root `BrowsingContext`s
`OrientationLock` is set using the normal `SyncedContext` machinery,
rather than combining the `AbortOtherOrientationPendingPromises`
message for a single message.
This commit fixes both Bug 1597413 and Bug 1597443.
Differential Revision: https://phabricator.services.mozilla.com/D70416
