This creates the print.modal_print_preview.enabled pref to manage
whether the tab modal print UI should be used and creates some
files we'll need for the UI to use.
Differential Revision: https://phabricator.services.mozilla.com/D83445
Uses of `-moz-appearance: none` are changed to `appearance: none`.
Uses of other values that are simply reverting the appearance back to
its default are changed to `appearance: auto`.
Uses of values in UA sheets that are defining the inherent appearance of
widgets are changed to:
appearance: auto;
-moz-default-appearance: <value>;
since those values are either no longer supported on (-moz-)appearance,
or are still supported but only in some limited form.
There are some uses of `-moz-appearance: textfield` on <input
type=number> elements that are renamed to `appearance: textfield`.
Differential Revision: https://phabricator.services.mozilla.com/D83430
This causes the browser to steal focus from any element that was focused prior
to the completion of the remoteness flip. This is particularly a problem for
fission because every cross-origin navigation requires a process switch.
This code is still necessary for "normal" session restores (see bug 1410591),
but focus is handled elsewhere for remote navigations.
Differential Revision: https://phabricator.services.mozilla.com/D82783
This works by hiding the window instead of skipping opening it. This seems safer, since
there are parts of webrtcUI that expect to call functions on the window.
Differential Revision: https://phabricator.services.mozilla.com/D83348
This also only updates per-category block information in the protections panel
while it's open or when it's about to be shown. To do this, the patch:
1. changes the `categoryItem` getter on all blockers to avoid memo'izing null when the popup is unavailable;
2. changes the `updateCategoryItem` method on all blockers to deal with `categoryItem` being null;
3. stops calling `updateCategoryItem` from the blockers' `init` method, instead delegating this responsibility
to gProtectionsHandler doing so when the popup first becomes available. Note that we still need (2) because
pref changes can trip us calling into `updateCategoryItem` anyway. We cannot avoid instantiating the pref
getters because they are relied on by some of the `isDetected` and `isBlocking` implementations.
4. reorganizes `onContentBlockingEvent` so it updates the icon, reports telemetry, and updates internal state -
but only updates the panel if it's visible, and otherwise simply memorizes the last event (which is just
a number!);
5. ensures showing the panel updates the panel's category data based on the memorized state from (4).
Differential Revision: https://phabricator.services.mozilla.com/D81926
In Bug 1638369 we added two new RSA-AES-GCM ciphersuites for web compatibility, but
did not add them to `all.js` so they weren't visible in about:config.
Since these are not mandatory ciphersuites to the TLS specification, they
should be configurable.
Differential Revision: https://phabricator.services.mozilla.com/D83192
This causes the browser to steal focus from any element that was focused prior
to the completion of the remoteness flip. This is particularly a problem for
fission because every cross-origin navigation requires a process switch.
This code is still necessary for "normal" session restores (see bug 1410591),
but focus is handled elsewhere (and more robustly) for navigations.
Differential Revision: https://phabricator.services.mozilla.com/D82783
This also only updates per-category block information in the protections panel
while it's open or when it's about to be shown. To do this, the patch:
1. changes the `categoryItem` getter on all blockers to avoid memo'izing null when the popup is unavailable;
2. changes the `updateCategoryItem` method on all blockers to deal with `categoryItem` being null;
3. stops calling `updateCategoryItem` from the blockers' `init` method, instead delegating this responsibility
to gProtectionsHandler doing so when the popup first becomes available. Note that we still need (2) because
pref changes can trip us calling into `updateCategoryItem` anyway. We cannot avoid instantiating the pref
getters because they are relied on by some of the `isDetected` and `isBlocking` implementations.
4. reorganizes `onContentBlockingEvent` so it updates the icon, reports telemetry, and updates internal state -
but only updates the panel if it's visible, and otherwise simply memorizes the last event (which is just
a number!);
5. ensures showing the panel updates the panel's category data based on the memorized state from (4).
Differential Revision: https://phabricator.services.mozilla.com/D81926
This also only updates per-category block information in the protections panel
while it's open or when it's about to be shown. To do this, the patch:
1. changes the `categoryItem` getter on all blockers to avoid memo'izing null when the popup is unavailable;
2. changes the `updateCategoryItem` method on all blockers to deal with `categoryItem` being null;
3. stops calling `updateCategoryItem` from the blockers' `init` method, instead delegating this responsibility
to gProtectionsHandler doing so when the popup first becomes available. Note that we still need (2) because
pref changes can trip us calling into `updateCategoryItem` anyway. We cannot avoid instantiating the pref
getters because they are relied on by some of the `isDetected` and `isBlocking` implementations.
4. reorganizes `onContentBlockingEvent` so it updates the icon, reports telemetry, and updates internal state -
but only updates the panel if it's visible, and otherwise simply memorizes the last event (which is just
a number!);
5. ensures showing the panel updates the panel's category data based on the memorized state from (4).
Differential Revision: https://phabricator.services.mozilla.com/D81926
Now that filesystem broker policy entries that depend on prefs can be
cached in the "common" policy object, let's do this wherever possible.
Partially fixes bug 1600189.
Differential Revision: https://phabricator.services.mozilla.com/D81424
When the SandboxBrokerPolicyFactory is constructed, prefs aren't
available, which constrains the cached subset of the content process
policy to entries that don't depend on prefs. Delaying the computation
until a content process is started removes that restriction.
(This also delays the reading of dynamic linker configuration to discover
library directories, so a test needs to be adjusted.)
Differential Revision: https://phabricator.services.mozilla.com/D81423
