We only use the contentBlockingAllowListPrincipal for excluding sites from content
blocking for top level documents. We don't need it in the content process and should
not compute it for every document.
Differential Revision: https://phabricator.services.mozilla.com/D100781
This removes nsIX509Cert.subjectAltNames and reduces potential attack surface
by avoiding parsing subject alternative names in C/C++. It also reduces PSM
reliance on NSS types.
Differential Revision: https://phabricator.services.mozilla.com/D101418
Syncing the container FeaturePolicy across BrowsingContext is actually
a bit more heavy-handed than necessary. We only ever need a container
FeaturePolicy when inheriting a FeaturePolicy in exactly the document
the container contains. Not every process that the tree the container
is a part of. So instead of storing a FeaturePolicy in a synced field,
we manually send it to the correct WindowGlobalChild (which
corresponds to a document) and retrieve it from there.
Differential Revision: https://phabricator.services.mozilla.com/D61479
Windows start blocking media by default (see the
media.block-autoplay-until-in-foreground pref).
If the document becomes visible from GetScriptHandlingObject(), we
hand-rolled our own UpdateVisibilityState and didn't call
MaybeActiveMediaComponents (which unblocks media playback).
It couldn't call it there before since given content docshells used
start as active, but now that they don't we can do that and fix the bug.
Differential Revision: https://phabricator.services.mozilla.com/D41438
This lifts a bunch of string conversions higher up the stack, but allows
us to make the servo code use utf-8 unconditionally, and seemed faster
in my benchmarking (see comment 0).
It should also make a bunch of attribute setters faster too (like
setting .cssText), now that we use UTF8String for them (we couldn't
because we couldn't specify different string types for the getter and
setters).
Differential Revision: https://phabricator.services.mozilla.com/D99590
There are two issues in our current setup
1) Input events which are occurring in the same tab are going to be lost
because sync XHR. We have event handling suppression for synx XHR, so input
events are going to be discarded.
2) Input events that are happening in another tab (same process as the
synx XHR tab) are not going to be delayed. This is not correct since
sync XHR should block the Javascript execution.
This patches fixes the above cases for when both TaskController and e10s are
enabled by suspending the InputTaskManager during sync XHR, which
delays the input event handling and keeps the events around.
Differential Revision: https://phabricator.services.mozilla.com/D90780
And have it mirror in the parent process more automatically.
The docShellIsActive setter in the browser-custom-element side needs to
be there rather than in the usual DidSet() calls because the
AsyncTabSwitcher code relies on getting an exact amount of notifications
as response to that specific setter. Not pretty, but...
BrowserChild no longer sets IsActive() on the docshell itself for OOP
iframes. This fixes bug 1679521. PresShell activeness is used to
throttle rAF as well, which handles OOP iframes nicely as well.
Differential Revision: https://phabricator.services.mozilla.com/D96072
Rework the MediaKeys class to shutdown when its parent inner window is destroyed
rather than the document it's created in. This is done to mitigate the case
where a MediaKeys is created in an about:blank document that has not yet
undergone its async load (i.e. blank document that will stay blank, blank
documents loading to other pages will still clobber their keys on load). This
specifically addresses cases where sites could create an iframe, not wait for
load, create a MediaKeys in the iframe, and then find the keys had become
unusable.
This is achieved by associating MediaKeys instances with their inner window and
having the window notify keys when a window is going to be destroyed. I decided
to use this approach rather than have MediaKeys observe for window destruction
for a few reasons:
- The keys would need to support weak references to use the observer service in
the desired way. Implementing this interface on the MediaKeys adds a
non-trivial level of complexity and means the keys would implement the WeakPtr
interface (already in place prior to this patch) and also the NS weak
reference interface, which I found confusing.
- If the inner window stores pointers to MediaKeys created in it, it can be self
aware of if EME activity is taking place within it. The allows us to better
identify EME activity in documents. Historically one of the ways we'd
determined EME activity by checking if media elements have MediaKeys attached,
but this had lead to issues where if MediaKeys are created but not attached
to a media element we overlook them. With this patch's changes, we can also
have a document check its inner window to see if there are any MediaKeys. This
patch uses this to extend our check to avoid bfcaching pages with EME content.
- There appears to be prior art using a similar approach for audio contexts and
peer connections, which I assume is sensible and I'm not reinventing the wheel
by following.
Differential Revision: https://phabricator.services.mozilla.com/D98641
This is a best-effort thing of course, but so is the rest of the
visibility threshold stuff in practice and this should be good enough.
Differential Revision: https://phabricator.services.mozilla.com/D98360
There are two issues in our current setup
1) Input events which are occurring in the same tab are going to be lost
because sync XHR. We have event handling suppression for synx XHR, so input
events are going to be discarded.
2) Input events that are happening in another tab (same process as the
synx XHR tab) are not going to be delayed. This is not correct since
sync XHR should block the Javascript execution.
This patches fixes the above cases for when both TaskController and e10s are
enabled by suspending the InputTaskManager during sync XHR, which
delays the input event handling and keeps the events around.
Differential Revision: https://phabricator.services.mozilla.com/D90780
A new `BrowsingContext` field has been added to track the active
browser window for the `:-moz-window-inactive` pseudoclass. This
field takes the place of `nsPIDOMWindowOuter::mIsActive`.
With this change `:-moz-window-inactive` is now fission compatible.
Differential Revision: https://phabricator.services.mozilla.com/D86422
A new `BrowsingContext` field has been added to track the active
browser window for the `:-moz-window-inactive` pseudoclass. This
field takes the place of `nsPIDOMWindowOuter::mIsActive`.
With this change `:-moz-window-inactive` is now fission compatible.
Differential Revision: https://phabricator.services.mozilla.com/D86422
This change removes docshell's `mTouchEventsOverride` and replaces it
with a new `BrowsingContext` field `TouchEventsOverrideInternal`.
All uses of the old field have been replaced and an override should
now work under fission when there are cross-origin descendent frames.
Differential Revision: https://phabricator.services.mozilla.com/D96414
This is to prevent issues with parsing the correct hostname for displaying and adding
exceptions for urls like view-source:.
Differential Revision: https://phabricator.services.mozilla.com/D94421
This is to prevent issues with parsing the correct hostname for displaying and adding
exceptions for urls like view-source:.
Differential Revision: https://phabricator.services.mozilla.com/D94421
In some edge cases involving shadow dom the selection code may get
confused and keep references to inside the shadow root (of <audio> in
this case).
Avoid crashing due to that in the printing code for now, bug.
Bug 1590379 tracks issues with selection handling inside shadow DOM.
Differential Revision: https://phabricator.services.mozilla.com/D94578
sizemode/displaymode media queries only affect a given browsing context
tree so there's no need to propagate the change to images in that case.
Differential Revision: https://phabricator.services.mozilla.com/D94422
Current page load telemetry probes are insufficient in performance RUM testing. FX_PAGE_LOAD_MS_2 will stop the timer when the user switches tabs or navigates off the page, while the current navigation probes include all content including about:blank, about:newtab, moz-extension, etc. This patch adds support for the following probes which do not suffer from those limitations:
PERF_PAGE_LOAD_TIME_MS
PERF_PAGE_LOAD_TIME_FROM_RESPONSESTART_MS
PERF_DOM_CONTENT_LOADED_TIME_MS
PERF_DOM_CONTENT_LOADED_TIME_FROM_RESPONSESTART_MS
PERF_FIRST_CONTENTFUL_PAINT_MS
PERF_FIRST_CONTENTFUL_PAINT_FROM_RESPONSESTART_MS
PERF_REQUEST_ANIMATION_CALLBACK_PAGELOAD_MS
PERF_REQUEST_ANIMATION_CALLBACK_NON_PAGELOAD_MS
Differential Revision: https://phabricator.services.mozilla.com/D94004
Recursive the things all :^)
The fix to the "corresponding node" bits in Document.cpp should be
pretty straight-forward. The fix in nsPrintJob is a bit more subtle:
The way printing selection works is literally "select everything else,
then call Selection.deleteFromDocument on that". We need to do the same
with shadow DOM, which involves skipping over shadow trees, and dealing
with selecting bits in ancestor trees as needed.
Note that for multi-range-selection case this technically relies on the
order of the ranges being shadow-tree-inclusive. We don't support
multi-range selection in shadow dom well, afaict, but I've added a
comment to the code to that effect.
Differential Revision: https://phabricator.services.mozilla.com/D93357
