This adds the boolean pref security.sandbox.content.headless (on Linux
only) which does two things:
1. Sets the MOZ_HEADLESS env var for content processes, so that they
don't initialize GTK and don't connect to the X server.
2. Disallows brokered access to parts of the filesystem used only for
graphics -- most critically connecting to the X11 socket itself, but
also opening GPU device nodes and the parts of sysfs used by Mesa, for
example.
This is experimental; use at your own risk.
Setting this pref will break native widgets, so it's also necessary to
set widget.disable-native-theme-for-content
Additionally, it breaks Flash and WebGL; see bug 1638466 for the latter.
Differential Revision: https://phabricator.services.mozilla.com/D81425
Now that filesystem broker policy entries that depend on prefs can be
cached in the "common" policy object, let's do this wherever possible.
Should also fix bug 1621231.
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.
Differential Revision: https://phabricator.services.mozilla.com/D81423
Not strictly necessary, but I noticed this while I was making changes:
AddDynamicPathList can be a simple static function instead of a private
static method, and doesn't need to be in the header.
Differential Revision: https://phabricator.services.mozilla.com/D81422
The central-as-beta simulation that caught this was before reftypes was enabled
by default. Most table tests can just use anyfunc to be MVP compatible. Testing
table.grow requires reftypes, and is conditioned on it being available.
Differential Revision: https://phabricator.services.mozilla.com/D81368
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
Now that XBL and xml:base are gone, and that <svg:use> is sane (using
shadow trees instead of NAC), we can just remove this, and fix this bug.
Differential Revision: https://phabricator.services.mozilla.com/D81553
When positioning overlay scrollbars, the code was previously taking the
visual viewport size and scaling it back up to the composition size using
the resolution. This works because overlay scrollbars don't take up any
space, and so the visual viewport size is exactly equal to the composition
size divided by the resolution. However, it's simpler to just use the
composition size because we can get that easily enough. And this fixes the
scrollbar positioning on the very first reflow, before the visual viewport
has been set on the presShell.
Eventually this might make it easier to do this for non-overlay scrollbars
as well, since those do take up layout space, and can't be positioned using
the "VV size multiplied by resolution" quantity, as that doesn't exactly
equal the composition size.
Differential Revision: https://phabricator.services.mozilla.com/D81277
The TryLayout code uses the composition size to figure out if the
scrollbar is needed or not. It computes something similar to the visual
viewport size (but assuming no scrollbars are taking up space) to do this.
There's no reason this code should be depending on whether or not the
visual viewport size is set in the presShell, so we can just remove the
condition. That way even on the very first reflow, when the visual viewport
will definitely not be set, we can correctly determine if the scrollbars
need to be laid out or not.
Differential Revision: https://phabricator.services.mozilla.com/D81276
It leaves parent pointers nulled out when it really shouldn't when
cloning shared sheets (if there's another suitable parent, we should use
that instead of nulling out).
Fix the code in StyleSheetInfo::RemoveSheet to handle all cases
(including nulling out when removing the only remaining sheet), and rely
on that instead.
Differential Revision: https://phabricator.services.mozilla.com/D81569
This is already handled in a different way on Windows.
For documents at the top level of their process (including OOP iframes), we can just set the flag rather than waiting for a message, since we can never get queries for such documents or descendants before parent process construction is complete.
Differential Revision: https://phabricator.services.mozilla.com/D81009
Consider the case where we have an expired entry in the cache, and we
load a new document.
We get an speculative load from the HTML parser. That's great, and we
see the entry is expired and actually fired the load.
But then, we actually get to the load that the <link> element performs,
and we see that we've already performed this load, so instead of peeking
the in-progress load, we go ahead and peek the expired "complete" cache
entry, which is not what we want.
By marking a load as performed only once it has finished, we avoid the
complete sheet cache, and glom onto the existing load instead, which is
the correct thing to do.
Differential Revision: https://phabricator.services.mozilla.com/D81318
Guard against nullptr access of missing p.impl.
Also change LinkStatus so is_initialized is no longer true and calling
code can early out if bind_program fails.
Differential Revision: https://phabricator.services.mozilla.com/D81421
The clones appear to be so that access for the tree view in preferences is quick. However, they don't need to clone the entire engine object - they just need three fields.
Additionally, this fixes reloading icons which was attempting to use 'uri' but that isn't defined, and so icons would fail to load if preferences was opened when a search engine is added.
Differential Revision: https://phabricator.services.mozilla.com/D80496
This patch additionally makes the search cache responsible for listening to notifications rather than being directly told by the search service to write the cache.
It also makes writes after init/reinit/maybeReloadEngines into delayed writes as they don't need to be immediate - the code already ensures we write any pending cache before reading, and that we write it before shutdown. Therefore, it doesn't matter if we wait a second or so.
Differential Revision: https://phabricator.services.mozilla.com/D80472
This patch makes it so whenever we encounter a corrupt database file we recrate
it and backup the corrupt file to a folder in the profile.
Differential Revision: https://phabricator.services.mozilla.com/D80051
Apparently I added these in the initial commit for RecursiveMutex. I'm
not quite sure what I was thinking, but we don't need them for the
RecursiveMutex itself. (We have them on the corresponding `*Auto*Lock`
classes, which are also `MOZ_RAII`.)
Differential Revision: https://phabricator.services.mozilla.com/D81345
When parsing frames, we only need to retrieve the first "@" index to split
the frame string and get the function name on one side, and the location on the
other side.
This patch removes the regex-based search we were doing for a simpler character
search. A test is added to ensure this works as expected, and snapshots that were
highlighting the issue are updated.
Differential Revision: https://phabricator.services.mozilla.com/D81519
Markus Stange
Jed Davis
Mitchell Hentges
Ryan Hunt
Bryce Seager van Dyk
Boris Chiou
Drew Willcoxon
chocos
Noemi Erli
Sylvestre Ledru
Emilio Cobos Álvarez
Nihanth Subramanya
Csoregi Natalia
David Major
sefeng
Kartikaya Gupta
Edwin Takahashi
James Teh
Luca Greco
Bert Peers
Mark Banner
Simon Giesecke
Agi Sferro
Nathan Froyd
Itiel
Vlad Filippov
Nicolas Chevobbe
caroline