Bug 1728967 dropped it but dom.webidl.crosscontext_hasinstance.enabled is
`true` outside Nightly and needs to be set to `false` in this file for the test.
Differential Revision: https://phabricator.services.mozilla.com/D126358
NSS shutdown happens in ShutdownXPCOM, after PSM (namely, nsINSSComponent) has
been shut down. Unloading temporarily-loaded PKCS#11 modules like the built-in
roots module and the osclientcerts module when PSM shuts down is redundant,
because this will happen when NSS shuts down anyway. Furthermore, doing so can
run afoul of some race conditions in NSS, so removing this redundant code is
the way to go.
Differential Revision: https://phabricator.services.mozilla.com/D126141
Previously we've removed data from the session store that aren't
currently in the current browsing context tree, but this is different
from what BackgroundSessionStorageManager considers to be a
session. After part 1 in this patch series, session store will save
exactly the view BackgroundSessionStorageManager has of the current
sessionStorage state.
Differential Revision: https://phabricator.services.mozilla.com/D125681
By storing the PrincipalInfo in the parent copy it is possible to
query the BackgroundSessionStorageManager withouth the need of a
preprocessing step matching resulting data to principals using the
browsing context tree. Instead the result from the query contains the
principal info.
To be able to initialize the parent actor lazily with a principal
info, it was needed to make clearing the storage be a less fine
grained transaction. Instead of sending updates per cache, we after
clearing in the child process we send a message to the parent that in
turn performs the same steps.
Differential Revision: https://phabricator.services.mozilla.com/D125680
This is a cut-down version of the 418986-2 testcase, with an explicit check that changes to
the resistFingerprinting pref will cause media queries to be re-evaluated and the resulting
computed styles to be updated at runtime.
Differential Revision: https://phabricator.services.mozilla.com/D126230
This adds `privacy.resistFingerprinting` to the list of prefs for which `nsPresContext` registers a callback,
because it is included among the prefs that `nsPresContext::PreferenceChanged` explicitly wants to handle.
We also sort the `gExactCallbackPrefs` array, to make it easier to scan its contents at a glance
in the future.
layout.css.prefers-contrast.enabled is dropped from being handled in PreferenceChanged, because that
doesn't actually work; we need to reload the document (re-parse the stylesheet) to notice the change.
Differential Revision: https://phabricator.services.mozilla.com/D125857
The test was relying on media queries not being recomputed, because it
ran something like this:
1. RFP off: add a bunch of images with class "testImage" to the
document. Then test all images with class "testImage".
2. RFP on: do the same.
Note that there's no "remove all images added in step 1" step between 1
and 2. So the test with rfp on was also testing the images from step 1.
This worked before because resistFingerprinting didn't trigger
recomputation of the previous images.
Differential Revision: https://phabricator.services.mozilla.com/D126152
This is a backout of the patch in bug 1581574 in the hope that it will fix the
crashes in bug 1731432.
Previously this write barrier was not required and we relied on the read
barrier, but it seems that may not be sufficient to allow us to mark gray roots
after the first GC slice. There are few ways that the value of a Heap<T> can be
observed without triggering the read barrier, and that could explain what's
happening here.
The contents of JS holders are cleared when they are removed from the holder
map, so that will also trigger the write barrier.
Differential Revision: https://phabricator.services.mozilla.com/D126253
With Fission/EFT work, we shouldn't call this function, but rely on the different
targets instead.
It was only used in the client from a test, which could be migrated easily.
(the test is still failing with EFT enabled, this will be taken care of in Bug 1730170)
Differential Revision: https://phabricator.services.mozilla.com/D126315
Wayland/Gtk sets drag state right after drag_motion event only.
While we're reading data for child process we're getting 'drag_motion' events from nested loop.
We don't know the final D&D state yet as we need reply from the child process.
When we set the D&D state latter, it's ignored by Gtk and D&D is considered as
canceled by client.
Right now we explicitly state 'drag denied' after D&D start until we have a reply from child process.
We're changing it to 'drag accepted' on Wayland until we have a reply from child process
and we also send the reply in WindowDragMotionHandler() to fulfill Wayland protocol needs.
It does not change final D&D state - we get the data only when child process requests it.
Differential Revision: https://phabricator.services.mozilla.com/D126226
Each time the related WindowGlobal is destroyed, the related target actor and connection will be destroyed.
But the destruction of the previous actor/connection happens *after* the creation of the new.
So that hasConnection() is always true on reload. On toolbox closing it should become false.
Regardless, we should always unregister the connectionchange.
The server may be destroyed by the very last actor/connection to be destroyed.
We might want to move this code directly into DevToolsServer, that may be clearer...
But that may break non-watcher setup, so better do that once we only support the watcher codepath.
Differential Revision: https://phabricator.services.mozilla.com/D126085
We weren't calling super class destroy method (Observable::destroy),
which is the one which will force ultimately unregistering the resize DOM listener.
Differential Revision: https://phabricator.services.mozilla.com/D126084