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
window.sizeToContent causes a minimized window to be restored, so we skip calling that if the
indicator is minimized. We call it instead once the indicator is restored.
Differential Revision: https://phabricator.services.mozilla.com/D82620
Use `GetFileType(HANDLE)` on Windows.
Unlike `HandleToFilename`, `GetFileType` is fast enough that we don't need to use a `SmallArrayLRUCache` for it.
The pipe I/Os should not be visible anymore in the startup tests.
Differential Revision: https://phabricator.services.mozilla.com/D82303
Caching filenames in 32-entry LRU array covers >95% of calls, and makes the average `Filename()` call 5 to 10 times cheaper.
browser_start_content_mainthreadio.js needed to be updated to handle operations that now have a filename thanks to the cache.
Since `ClearPoisonIOInterposer()` is never called (see bug 1647107), during Firefox shutdown we put LRUCache in a shutdown mode, which bypasses the cache in case it is still used at that time.
Differential Revision: https://phabricator.services.mozilla.com/D79767
ts_paint depends on the first MozAfterPaint in the content window, not in the
browser as I had thought. After MozAfterPaint, it pings the parent process and
waits for a response (see `TalosPowers.loadPromise`), and then it ends. It will
wait up to 500ms for the response before timing out. Source:
https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/startup_test/tspaint_test.html
At first I modified UrlbarProviderSearchTips to wait on
`browser-delayed-startup-finished`, but the jsm kept appearing in ts_paint
profiles, and that's how I found out the above. So that's not sufficient.
There's already a promise in browser.js for waiting on the first paint in the
first content window, but it's "private." I added a public getter for it and
changed the name so it's clearer that it's related to the first content window,
not the browser window.
I also added a 500ms timeout just like the worst case in ts_paint.
Both checks (paint and the timeout) are done for a particular browser window
only the first time UrlbarProviderSearchTips sees it.
Finally, UrlbarProviderSearchTips can avoid importing BrowserWindowTracker
during startup by having browser.js pass the window to its `onLocationChange`. I
saw the BrowserWindowTracker.jsm import in some profiles while working on this.
With these changes, UrlbarProviderSearchTips no longer appears in ts_paint
profiles when I run it locally -- except when it is imported by
UrlbarProvidersManager, which ultimately happens due to setting the placeholder
text in the urlbar input. But even that doesn't appear in every profile.
I've also included the reordering of checks from a previous version of this
patch. That's still worth doing in general even if it's no longer relevant to
ts_paint.
Differential Revision: https://phabricator.services.mozilla.com/D80799
Cameron McCormack
Gijs Kruitbosch
Dão Gottwald
Christoph Kerschbaumer
Kashav Madan
Bogdan Tara
Mike Conley
Frederik Braun
Emma Malysz
julianwels
Dimi Lee
Tarek Ziadé
Sebastian Streich
Vlad Filippov
Micah Tigley
Emilio Cobos Álvarez
Kris Maglione
J.C. Jones
Cosmin Sabou
pbz
Butkovits Atila
Jed Davis
Mark Banner
Matt Woodrow
Severin
Dave Townsend
Sebastian Hengst
Gerald Squelart
Dorel Luca
Andrew Park
Coroiu Cristina
Andrei Cristian Petcu
Razvan Maries
Yura Zenevich
Erica Wright
Julian Descottes
Matthew Noorenberghe
Alphan Chen
Narcis Beleuzu
Csoregi Natalia
ssengupta
Noemi Erli
Sarah Bird
alwu
Jan Horak
Bryce Seager van Dyk
Drew Willcoxon