Acquiring the lock is moved from CacheFile::RemoveInput() to CacheFileInputStream::Release(). This fixes the data race and is consistent with CacheFile::RemoveOutput() which is also called under the lock.
Differential Revision: https://phabricator.services.mozilla.com/D62504
--HG--
extra : moz-landing-system : lando
First simple attempt at fixing this. The target getter in the DOM panel already
refers to the current toolbox top-level target. There doesn't seem to be a need
to change this as this is the only target the DOM panel cares about.
So, I'm only adding a listener for new top-level targets and refreshing the
panel when that happens, just like we do on navigation.
Am I missing something?
Differential Revision: https://phabricator.services.mozilla.com/D60013
--HG--
extra : moz-landing-system : lando
Currently the blocklist can block groups of devices, called a
DeviceFamily. However this only allows us to check specific IDs and not
ranges of device IDs like we do currently for the WebRender allowlist.
This patch allows a device family to now specify start and end values
for device IDs we want to match in the blocklist rule.
Differential Revision: https://phabricator.services.mozilla.com/D62324
--HG--
extra : moz-landing-system : lando
As part of the WebRender rollout, we have been only allowing users
meeting particular platform, battery and screen size requirements (among
others) to get WebRender by default. This patch adds support for battery
and screen size filters in the blocklist rules to allow us to control
that more easily. It also adds kludgey support for checking for recent
Windows 10 build numbers for allowlist purposes; implementing this the
proper way would require an implementation like driver version checks,
which are much more complicated than most of the rules.
Differential Revision: https://phabricator.services.mozilla.com/D62323
--HG--
extra : moz-landing-system : lando
The blocklist currently works by checking the current configuration
against a set of GfxDriverInfo rules. We stop searching as soon as we
find the first match, and return whatever status code that has.
This patch adds a second pass for features marked for allowing. The
current blocklisting rules will still apply as normal. However it will
then review the allowlist rules using the same logic. If we don't get
a match, then we block the feature otherwise we use the allow status
code given in the rule.
New status codes introduced as part of this patch are as follows:
DENIED - Did not match any rules on the allowlist.
ALLOW_ALWAYS - Same as STATUS_OK but passed the allowlist.
ALLOW_QUALIFIED - Same as ALLOW_ALWAYS but should be controlled by
our qualified preference for experimentation purposes.
Differential Revision: https://phabricator.services.mozilla.com/D62322
--HG--
extra : moz-landing-system : lando
Remove some dependencies on JSRuntime by storing flags on the Zone to indicate whether a zone is the atoms zone or the self hosting zone.
Differential Revision: https://phabricator.services.mozilla.com/D62620
--HG--
extra : moz-landing-system : lando
`HTMLEditor::CollapseAdjacentTextNodes()` collects editable text nodes first so
that the array can be array of `dom::Text`. Additionally, using
`DOMSubtreeIterator` instead of `ContentSubtreeIterator` makes the code easier
to understand.
Differential Revision: https://phabricator.services.mozilla.com/D61973
--HG--
extra : moz-landing-system : lando
Add support to the yaml reader and writer to be able to specify
that a primitive should set the PREFER_COMPOSITOR_SURFACE flag.
This flag is not currently used, but in future will signal the
picture caching code to promote a primitive to draw on a native
compositor surface where possible.
Differential Revision: https://phabricator.services.mozilla.com/D62693
--HG--
extra : moz-landing-system : lando
While making the change in the previous patch (to make the dom panel use
the targetList API), and writing a test for it, I stumbled upon a weird
issue that I don't think we've encountered so far.
The console's actor method evaluateJSAsync does things a bit differently
than other methods. It spawns the work it needs to do, but does not wait
for it to be done, and immediately returns an ID to the client.
Later, when the work is done, it sends an event back to the client with
the response.
It's then up to the client to use the ID provided in the immediate response
and match it against the incoming event to verify that this is, indeed,
the right response.
In all cases we've seen so far, the event comes back after the initial
method response. This seems logical as evaluateJSAsync uses an
executeSoon helper to spawn the work needed in the next event loop.
Now, the case I have seen as witnessed by the test I added is that,
sometimes, the event actually comes back before the initial response.
Because both things go through the protocol.js message handling, and
because all of it is asynchronous, it may indeed happen. There's no
guaranty at the protocol level to avoid this.
So, my approach here is to simply avoid this to happen from the client
side. I don't think we should be doing a generic fix in protocol.js for
this, but instead clients should be prepared for these things to happen.
Differential Revision: https://phabricator.services.mozilla.com/D62417
--HG--
extra : moz-landing-system : lando
Add duration estimates to push summary. Refactored preview script - needed to be moved in order to import module.
Differential Revision: https://phabricator.services.mozilla.com/D61195
--HG--
rename : tools/tryselect/formatters/preview.py => tools/tryselect/preview.py
extra : moz-landing-system : lando
If the CSS filter was enabled, when the user would navigate to a page
on a different origin, the CSS Warnings from the new page wouldn't
be displayed in the console.
This is related to how we manage the CSS Warnings. Since emitting those
messages is costly, we only do so when the console is opened, if
the user already set the filter, or when they turned it on.
The issue is that it was only done on the main target, and only
when the console would start, or when the user clicked on the css
filter button.
So with Fission enabled, we could switch to a new target, but we
wouldn't trigger the code that parses the stylesheets of the new
page.
The browser_webconsole_message_categories was asserting this issue,
and is now fixed (after setting the proper target switching target).
Differential Revision: https://phabricator.services.mozilla.com/D61558
--HG--
extra : moz-landing-system : lando
This adds the pref to the browser_webconsole_inspect_cross_domain_object.js test.
The test was modified a bit to not navigate, otherwise we don't get the connection
to the target iframe.
Differential Revision: https://phabricator.services.mozilla.com/D61560
--HG--
extra : moz-landing-system : lando
This patch sets the pref for tests where it's needed (often
when the test navigates from an origin to another).
When possible, the skip-if=fission tag is removed.
For remaining issue, referencing to the bug where we should
re-enable those tests.
Differential Revision: https://phabricator.services.mozilla.com/D61559
--HG--
extra : moz-landing-system : lando
The function is changed to detect if we're going to navigate to
a different origin, and if fission and target switching are enabled,
will wait for the switched-target event to ensure devtools are
fully ready after a navigation.
Differential Revision: https://phabricator.services.mozilla.com/D62413
--HG--
extra : moz-landing-system : lando
The id was retrieved by transforming the map into an array
and getting the last element of it. This was slow and
allocatiing a lot of memory when the messages Map contained
a lot of elements.
This patch make it so we're now storing the last message
id directly in the state so we can get it in a cheaper way.
Differential Revision: https://phabricator.services.mozilla.com/D62185
--HG--
extra : moz-landing-system : lando
The original check, `currentContent != startContent`, is to skip the element we started on in frame traversal.
This would happen for instance on a scrollable element, where frame traversal could return the element again.
However, in shadow dom case, the frame traversal may start on a redirected shadow host, where `startContent` is still the original start element.
Differential Revision: https://phabricator.services.mozilla.com/D61566
--HG--
rename : testing/web-platform/tests/shadow-dom/focus/focus-tabindex-order-shadow-zero.html => testing/web-platform/tests/shadow-dom/focus/focus-tabindex-order-shadow-zero-host-scrollable.html
extra : moz-landing-system : lando
The checks for `*TopLevelScopeOwner` are to skip the scope that we have already checked.
But when the shadow host is scrollable, we will traverse anonymous children for the scroll frame first in frame traversal and `oldTopLevelScopeOwner` will be reset.
Then we don't realize that we have already checked the host's scope.
Differential Revision: https://phabricator.services.mozilla.com/D60923
--HG--
rename : testing/web-platform/tests/shadow-dom/focus/focus-tabindex-order-shadow-zero-host-not-set.html => testing/web-platform/tests/shadow-dom/focus/focus-tabindex-order-shadow-zero-host-not-set-scrollable.html
extra : moz-landing-system : lando
With the old constants the page alloc slots would fill up quickly and the hit
rate would quickly drop below 20%.
With the new constants the alloc slots don't fill up so quickly and the hit
rate remains at or near 100% for a lot longer. Also, page allocs are recycled
more slowly, which should increase the likelihood of UAFs being detected
correctly.
Differential Revision: https://phabricator.services.mozilla.com/D62539
--HG--
extra : moz-landing-system : lando
Specifically, the number of page allocs in use, and the page alloc hit rate.
Differential Revision: https://phabricator.services.mozilla.com/D62538
--HG--
extra : moz-landing-system : lando
Masatoshi Kimura
Michal Novotny
Arthur Iakab
Csoregi Natalia
Simon Giesecke
Nicolas Chevobbe
Patrick Brosset
Andrew Osmond
Martin Stransky
Emilio Cobos Álvarez
Jon Coppeard
Masayuki Nakano
Thiago Arrais
Jan Odvarko
Glenn Watson
shravanrn@gmail.com
Dão Gottwald
Julien Cristau
Daisuke Akatsuka
Mark Banner
Simon Fraser
Benjamin Bouvier
Andrea Marchesini
Pranav Pandey
Mihai Alexandru Michis
Henrik Skupin
Edgar Chen
Nicholas Nethercote
aarushivij