Windows does not fire any DataPackage event when a user selects copy action from the OS dialog, potentially causing never-resolved promise. Windows still does not provide any other way to detect that action, even on Windows 11.
Per https://github.com/w3c/web-share/issues/188 Chromium gave up and decided not to wait for user action.
Given that Microsoft is not expected to fix the situation anytime soon, it's probably better to follow what others do.
Depends on D121420
tmp
Differential Revision: https://phabricator.services.mozilla.com/D121421
CLOSED TREE
Backed out changeset aa2915f66825 (bug 1641280)
Backed out changeset 080107249a1c (bug 1641280)
Backed out changeset b183dae47176 (bug 1641280)
Windows does not fire any DataPackage event when a user selects copy action from the OS dialog, potentially causing never-resolved promise. Windows still does not provide any other way to detect that action, even on Windows 11.
Per https://github.com/w3c/web-share/issues/188 Chromium gave up and decided not to wait for user action.
Given that Microsoft is not expected to fix the situation anytime soon, it's probably better to follow what others do.
Depends on D121420
tmp
Differential Revision: https://phabricator.services.mozilla.com/D121421
This is a large refactoring of the DocumentChannel process switch codepath,
with the end goal of being better able to support future process switch
requirements such as dynamic isolation on android, as well as the immediate
requirement of null principal handling.
The major changes include:
1. The logic is in C++ and has less failure cases, meaning it should be harder
for us to error out unexpectedly and not process switch.
2. Process selection decisions are more explicit, and tend to rely less on
state such as the current remoteType when possible. This makes reasoning
about where a specific load will complete easier.
3. Additional checks are made after a "WebContent" behavior is selected to
ensure that if an existing document in the same BCG is found, the load will
finish in the required content process. This should make dynamic checks such
as Android's logged-in site isolation easier to implement.
4. ProcessIsolation logging is split out from DocumentChannel so that it's
easier to log just the information related to process selection when
debugging.
5. Null result principal precursors are considered when performing process
selection.
Other uses of E10SUtils for process selection have not yet been migrated to the
new design as they have slightly different requirements. This will be done in
follow-up bugs.
Differential Revision: https://phabricator.services.mozilla.com/D120673
This is a large refactoring of the DocumentChannel process switch codepath,
with the end goal of being better able to support future process switch
requirements such as dynamic isolation on android, as well as the immediate
requirement of null principal handling.
The major changes include:
1. The logic is in C++ and has less failure cases, meaning it should be harder
for us to error out unexpectedly and not process switch.
2. Process selection decisions are more explicit, and tend to rely less on
state such as the current remoteType when possible. This makes reasoning
about where a specific load will complete easier.
3. Additional checks are made after a "WebContent" behavior is selected to
ensure that if an existing document in the same BCG is found, the load will
finish in the required content process. This should make dynamic checks such
as Android's logged-in site isolation easier to implement.
4. ProcessIsolation logging is split out from DocumentChannel so that it's
easier to log just the information related to process selection when
debugging.
5. Null result principal precursors are considered when performing process
selection.
Other uses of E10SUtils for process selection have not yet been migrated to the
new design as they have slightly different requirements. This will be done in
follow-up bugs.
Differential Revision: https://phabricator.services.mozilla.com/D120673
Add a pref to control if Firefox to disallow relaxing the referrer
policy for cross-site requests. If it's set, we will ignore
'unsafe-url', 'no-referrer-when-downgrade' and
'origin-when-cross-origin' for cross-site requests.
Differential Revision: https://phabricator.services.mozilla.com/D119971
This is a large refactoring of the DocumentChannel process switch codepath,
with the end goal of being better able to support future process switch
requirements such as dynamic isolation on android, as well as the immediate
requirement of null principal handling.
The major changes include:
1. The logic is in C++ and has less failure cases, meaning it should be harder
for us to error out unexpectedly and not process switch.
2. Process selection decisions are more explicit, and tend to rely less on
state such as the current remoteType when possible. This makes reasoning
about where a specific load will complete easier.
3. Additional checks are made after a "WebContent" behavior is selected to
ensure that if an existing document in the same BCG is found, the load will
finish in the required content process. This should make dynamic checks such
as Android's logged-in site isolation easier to implement.
4. ProcessIsolation logging is split out from DocumentChannel so that it's
easier to log just the information related to process selection when
debugging.
5. Null result principal precursors are considered when performing process
selection.
Other uses of E10SUtils for process selection have not yet been migrated to the
new design as they have slightly different requirements. This will be done in
follow-up bugs.
Differential Revision: https://phabricator.services.mozilla.com/D120673
I tied it to the use-theme-accent bit in non-native-theme just for
convenience (so that form controls just react to this).
This works nicely, but I didn't turn this on by default because the
accessiblecaret images are hardcoded-blue pngs, and they look ugly
without being the same color as the native accent.
Differential Revision: https://phabricator.services.mozilla.com/D120898
Add initial support for the color-scheme CSS property, allowing pages to
choose between light and dark system colors per-element, and such.
Things that are left to do so that this can be enabled by default:
* Dark system colors on Windows / Android / Standins.
* Dark Canvas/CanvasText/Link visited colors (which right now are set
via PreferenceSheet).
* Dark form controls in nsNativeBasicTheme.
* Processing the color-scheme meta tag to fill-in
Document::mColorSchemeBits.
But this seems like enough progress to be landable on its own.
Differential Revision: https://phabricator.services.mozilla.com/D120843
Alias -apple-system to it, and put it behind a pref for now. This is
pretty boring (read: uncontroversial hopefully) code. The follow-up work
is modifying StaticPresData to look up the fonts using system APIs,
probably. Maybe a bit more work if on macOS they can't be named.
Differential Revision: https://phabricator.services.mozilla.com/D119984
Add prefs:
* webgl.enable-renderer-query: true
* webgl.sanitize-unmasked-renderer: false
Rename prefs:
* webgl.renderer-string-override => webgl.override-unmasked-renderer
* webgl.vendor-string-override => webgl.override-unmasked-vendor
webgl.enable-renderer-query is treated as false if RFP is enabled.
webgl.override-unmasked-renderer overrides UNMASKED_RENDERER and
is then sanitized for RENDERER if enabled.
Differential Revision: https://phabricator.services.mozilla.com/D120775
The accent-color computation right now chooses between black and white,
which is not ideal.
I tried to make it so that authors could choose the foreground colors in
the linked CSSWG issue from the comment, but that didn't go anywhere.
I think choosing a contrasting color that is in-line and contrasting
enough with the accent-color chosen by the page when darkening is better
than just black or white.
If we want the black-or-white behavior we can just change
layout.css.accent-color.target-contrast-ratio to something large enough.
https://accent-color.glitch.me/ is a nice playground to see this patch
in action.
Differential Revision: https://phabricator.services.mozilla.com/D120723
