Document::GetBrowsingContext uses a WeakPtr<nsIDocShell> so we can't do
that. But we have all the other media emulation data and so on in the
pres context which we can access off the main thread for style, so move the
override code there.
Differential Revision: https://phabricator.services.mozilla.com/D128673
Remove the follow-firefox-theme pref as now that's default everywhere,
and document better the behavior of the color-scheme property by
reworking and commenting the logic on it a bit.
Differential Revision: https://phabricator.services.mozilla.com/D128610
Given all our UI is using -moz-toolbar-prefers-color-scheme, this seems
like a more reasonable default nowadays. Allow for it to be
configurable via the existing pref.
Differential Revision: https://phabricator.services.mozilla.com/D128527
This shouldn't change behavior, but I find it a bit easier to reason
about (and should be marginally faster by not doing double attribute
lookups, but not like the should usually matter).
Differential Revision: https://phabricator.services.mozilla.com/D128389
This shouldn't change behavior, but I find it a bit easier to reason
about (and should be marginally faster by not doing double attribute
lookups, but not like the should usually matter).
Differential Revision: https://phabricator.services.mozilla.com/D128389
There are a lot of check of `Document`'s editable state **with** comments. This
means that it's unclear for developers that only `Document` node is editable in
design mode.
Additionally, there are some points which use composed document rather than
uncomposed document even though the raw API uses uncomposed document. Comparing
with the other browsers, checking uncomposed document is compatible behavior,
i.e., nodes in shadow trees are not editable unless `contenteditable`.
Therefore, `nsINode` should have a method to check whether it's in design mode
or not.
Note that it may be called with a node in UA widget. Therefore, this patch
adds new checks if it's in UA widget subtree or native anonymous subtree,
checking whether it's in design mode with its host.
Differential Revision: https://phabricator.services.mozilla.com/D126764
- Adding a test to validate behavior on non-tracking first-party requests
- Correct the result of a tracking same-origin request (now hasStorageAccess() == false when cookiePolicy = 2)
- Add check near the top of Document::HasStorageAccess to immediately return false when cookiePolicy is REJECT.
Differential Revision: https://phabricator.services.mozilla.com/D126399
This patch changes the way how we decide to expose the privilege SSA to
document interface. We will expose the interface for system principal
and the content script of the webcompat extension only.
Differential Revision: https://phabricator.services.mozilla.com/D125959
Unsuppressing is done only if the page can use stylesheet cache. That should mean the
load isn't a cold load and also some other resources may be cached and thus
painting could happen sooner.
There is currently a regression around dom.ipc.processCount.webIsolated handling, but the
testing has been done with dom.ipc.processCount.webIsolated==1, and the patch for bug 1731792
should give back similar behavior as what process count 1 has.
Differential Revision: https://phabricator.services.mozilla.com/D125878
Priviously, the ContentBlocking::ShouldAllowAccessFor() checkes don't
check if the storage permission was came from the allowList or not. This
patch changes that and it will check if the channel/window is
allowlisted at the same moment as checking the ContentBlockingAllowList.
It returns early if the channel/window is in the allowList.
Differential Revision: https://phabricator.services.mozilla.com/D126278
This version doesn't change SetContainer handling, since it seems to be tricky for the top level page.
So only activity change notification is fired and IsActive() is updated.
The comment about IsActive() was wrong even with the old bfcache implementation.
(I did check that it returned false when the page was in bfcache and many of the activity observers rely on that)
The changes to HTMLMediaElement are needed to ensure page can enter bfcache..
Differential Revision: https://phabricator.services.mozilla.com/D124684
I have no idea how to make the test result stable because the intermittent
failure is caused by a race of `IMEContentObserver`'s content query performend
at vsync and `keypress` event after the `keydown` event. Therefore, I try to
fix the root cause of the failure.
There are two paths reaching a public method of editor with pending
notifications. One is `keypress` event listener of the editor. The other is
`execCommand` related methods of `Document`. Therefore, we should make them
flush pending notifications before accessing editor, but the cost may be too
expensive. So we should consider whether we should flush pending notifications
or not as far as later.
Note that we cannot fix the `beforeinput` cases because flushing pending
notifications after dispatching `beforeinput` event may cause oranges. It'll
be fixed while I'm working on bug 1710784.
Differential Revision: https://phabricator.services.mozilla.com/D125805
SetContainer handling is similar to what DocumentViewer does for the old bfcache implementation.
(The old implementation hides it quite well).
The changes to HTMLMediaElement are needed to ensure page can enter bfcache.
Removed erroneous MOZ_ASSERT in nsPresContext, it is ok to trigger that code path in the new implementation.
And the Run() method of the relevant nsIRunnable already deals with that case.
Differential Revision: https://phabricator.services.mozilla.com/D124684
This field will be useful to JS code such as JSWindowActors which need to be
able to detect when their WindowContext is no longer active.
Differential Revision: https://phabricator.services.mozilla.com/D124098
I tried to keep the changes minimal in this case.
We may need some more changes to Document::UnsuppressEventHandlingAndFireEvents to make it work
well with Fission (but that Fission work is totally unrelated to this fix).
Differential Revision: https://phabricator.services.mozilla.com/D123389
The test is in theory racy, but trying to limit the cases when it might behave badly
by running it on opt desktop builds only. Without the patch the 'period' check takes over 400ms locally and with the
patch 1-3ms.
The changes are just trying to optimize execution, not change the behavior.
Use of SuppressedMicroTasks is perhaps a bit odd, but it helps keeping
SavedMicroTaskQueue and similar code simple.
Differential Revision: https://phabricator.services.mozilla.com/D122290
This will make implementing the new behavior behind a pref
really straight-forward, and is generally nicer.
Depends on D121858
Differential Revision: https://phabricator.services.mozilla.com/D121705
In the case of reflowing caused by full zoom changes, the mDisplaySize isn't
changed, whereas mMobileViewportSize should be changed.
Differential Revision: https://phabricator.services.mozilla.com/D120190
There are a number of modules that we import from C++ and can't continue
running without. We have a number of crashes for some of those failed loads. A
lot of them are from OOMs or corruption, but we're not sure about the rest.
This patch adds a crash annotation with the details of the error wherever we
abort for failing to load a module.
Differential Revision: https://phabricator.services.mozilla.com/D120290
There are a number of modules that we import from C++ and can't continue
running without. We have a number of crashes for some of those failed loads. A
lot of them are from OOMs or corruption, but we're not sure about the rest.
This patch adds a crash annotation with the details of the error wherever we
abort for failing to load a module.
Differential Revision: https://phabricator.services.mozilla.com/D120290
Instead, fix up the various content data structures when the stylesheet
is mutated. This makes reading a stylesheet not disable style sharing.
Differential Revision: https://phabricator.services.mozilla.com/D115203
Currently, `increasefontsize`, `decreasefontsize`, `gethtml`, `heading`,
`contentReadOnly`, `readonly` and `insertBrOnReturn` commands are supported
only by Gecko. So, if nobody uses some or all of them, we can drop the
unused commands.
For saving the space of `Document.mUseCounters`, this patch groups
`Document.queryCommandState` and `Document.queryCommandValue` because they
are both getter of the command. The difference is not important. And also
this patch groups `Document.queryCommandSupported` and
`Document.queryCommandEnabled` because they may be used for feature detection
and the difference is not important.
Differential Revision: https://phabricator.services.mozilla.com/D118956
Instead, fix up the various content data structures when the stylesheet
is mutated. This makes reading a stylesheet not disable style sharing.
Differential Revision: https://phabricator.services.mozilla.com/D115203
Instead, fix up the various content data structures when the stylesheet
is mutated. This makes reading a stylesheet not disable style sharing.
Differential Revision: https://phabricator.services.mozilla.com/D115203
The observers take care of unregistering when they need to. Instead,
make the ResizeObservation keep the element alive just like
nsMutationReceiver keeps the mutation observer alive.
Differential Revision: https://phabricator.services.mozilla.com/D118477
The observers take care of unregistering when they need to. Instead,
make the ResizeObservation keep the element alive just like
nsMutationReceiver keeps the mutation observer alive.
Differential Revision: https://phabricator.services.mozilla.com/D118477
The public key pinning implementation is much less complex than the HSTS
implementation, and only needs a small subset of the parameters of the latter.
Furthermore, the information it relies on is static, and so is safe to access
from content processes. This patch separates the two implementations, thus
simplifying both of them and avoiding some unnecessary IPC calls in the
process.
Differential Revision: https://phabricator.services.mozilla.com/D117096
The public key pinning implementation is much less complex than the HSTS
implementation, and only needs a small subset of the parameters of the latter.
Furthermore, the information it relies on is static, and so is safe to access
from content processes. This patch separates the two implementations, thus
simplifying both of them and avoiding some unnecessary IPC calls in the
process.
Differential Revision: https://phabricator.services.mozilla.com/D117096
The public key pinning implementation is much less complex than the HSTS
implementation, and only needs a small subset of the parameters of the latter.
Furthermore, the information it relies on is static, and so is safe to access
from content processes. This patch separates the two implementations, thus
simplifying both of them and avoiding some unnecessary IPC calls in the
process.
Differential Revision: https://phabricator.services.mozilla.com/D117096
The change to DoNotifyPossibleTitleChange handling is needed so that we flush the pending title change
before adding a new active entry.
aUpdateEntryInSessionHistory is a bit odd name, since it is really about SHIP only. The patch isn't trying to
fix non-SHIP UI issues, but just give Fission similar behavior what Chrome has.
Differential Revision: https://phabricator.services.mozilla.com/D116504
This patch factors the DOM related sizes in nsWindowSizes to its own
struct, such that callers can easily acess DOM memory sizes.
Differential Revision: https://phabricator.services.mozilla.com/D111317
Running AssertDocGroupMatchesKey() on an unlinked document can cause
a crash in debug builds, so pass in the group directly, because all
of the callers are Documents so they already have it.
Differential Revision: https://phabricator.services.mozilla.com/D115272
This is necessary to remove the Init methods from principals, allowing
immutable fields to be marked as const and clearly separated from mutable
fields to improve threadsafety.
Differential Revision: https://phabricator.services.mozilla.com/D115091
Replace JS pageload proportion probes with absolute time measurements and add new probes to measure GC and main thread parsing impact during page load.
Differential Revision: https://phabricator.services.mozilla.com/D114388
When `document.execCommand("selectall")` is called, it should behave exactly
same as "Select All" in the UI for compatibility with the other browsers.
And also this patch fixes a bug of the WPT. `selectionchange` event should
be fired, but asynchronously. Therefore, Chrome also fails the check.
Differential Revision: https://phabricator.services.mozilla.com/D112307
This changes the test a bit. It doesn't test BroadcastChannel's postMessage anymore, but receiving the message.
I can't see how postMessage could be tested, since given the new setup, no one should have access to it anymore.
This is functionally now very similar to another test I wrote recently, but I think it is fine to keep this too.
Differential Revision: https://phabricator.services.mozilla.com/D109539
Document::CrossOriginIsolated() was assuming this wasn't possible,
so when you print from an isolated page from a different site, then we
end up with the wrong docgroup.
Differential Revision: https://phabricator.services.mozilla.com/D110988
Similifies use of EventStates and ObjectType/FallbackType enums since most states they represented are no longer valid with the removal of NPAPI plugins. The state machine for (unsupported) plugin elements is now much simpler but still distinguishes between HTML fallbacks, fallbacks leading to a "BROKEN" state (e.g. failing to load the image the element refers to), and fallbacks that would simply lead the element to occupy an empty region. The last type of fallback is behind a pref "layout.use-plugin-fallback" and is disabled by default.
Simplifying the state machine allows us to clean up nsObjectLoadingContent. We also update many of the enums which refered to plugins, which would otherwise get confusing.
Differential Revision: https://phabricator.services.mozilla.com/D107158
Similifies use of EventStates and ObjectType/FallbackType enums since most states they represented are no longer valid with the removal of NPAPI plugins. The state machine for (unsupported) plugin elements is now much simpler but still distinguishes between HTML fallbacks, fallbacks leading to a "BROKEN" state (e.g. failing to load the image the element refers to), and fallbacks that would simply lead the element to occupy an empty region. The last type of fallback is behind a pref "layout.use-plugin-fallback" and is disabled by default.
Simplifying the state machine allows us to clean up nsObjectLoadingContent. We also update many of the enums which refered to plugins, which would otherwise get confusing.
Differential Revision: https://phabricator.services.mozilla.com/D107158
Although these commands supported supported only by Gecko, we shouldn't stop
supporting them unless we know the usage in the wild. Therefore, this patch
adds the handling code for `TextEditor` too.
Differential Revision: https://phabricator.services.mozilla.com/D108571
Currently, `Document` checks it only with whether the document is editable
or not. Only with this check, `execCommand` and the other related methods
work only when there is `contenteditable`.
Therefore, this patch makes it to check whether the target is editable or not
with target editor.
Differential Revision: https://phabricator.services.mozilla.com/D108570
For making `execCommand` and related methods with `<input>` and `<textarea>`
even if they are in `contenteditable` and focused, command should be handled
in active editor (focused editor if in foreground window and tab).
However, some commands should be handled by `HTMLEditor` even if an `TextEditor`
has focus. Therefore, this patch adds new enum class which have 3 state into
`InternalCommandData` and makes `AutoEditorCommandTarget` consider it with the
enum class.
Note that the new failures about `contentReadOnly` command will be fixed by
a following patch.
Differential Revision: https://phabricator.services.mozilla.com/D108569
This will guarantee that when `<input>` or `<textarea>` is in `contenteditable`,
`execCommand` and the other related methods work with same command class
instance and same command context (in this case, it's editor instance).
Differential Revision: https://phabricator.services.mozilla.com/D108568
Editor command should be handled in same command table between `ExecCommand`
and the other related methods. However, currently, only `ExecCommand` does
optimized things. For using same logic in the other methods, the code should
be in an independent stack class.
Differential Revision: https://phabricator.services.mozilla.com/D108567
Although these commands supported supported only by Gecko, we shouldn't stop
supporting them unless we know the usage in the wild. Therefore, this patch
adds the handling code for `TextEditor` too.
Differential Revision: https://phabricator.services.mozilla.com/D108571
Currently, `Document` checks it only with whether the document is editable
or not. Only with this check, `execCommand` and the other related methods
work only when there is `contenteditable`.
Therefore, this patch makes it to check whether the target is editable or not
with target editor.
Differential Revision: https://phabricator.services.mozilla.com/D108570
For making `execCommand` and related methods with `<input>` and `<textarea>`
even if they are in `contenteditable` and focused, command should be handled
in active editor (focused editor if in foreground window and tab).
However, some commands should be handled by `HTMLEditor` even if an `TextEditor`
has focus. Therefore, this patch adds new enum class which have 3 state into
`InternalCommandData` and makes `AutoEditorCommandTarget` consider it with the
enum class.
Note that the new failures about `contentReadOnly` command will be fixed by
a following patch.
Differential Revision: https://phabricator.services.mozilla.com/D108569
This will guarantee that when `<input>` or `<textarea>` is in `contenteditable`,
`execCommand` and the other related methods work with same command class
instance and same command context (in this case, it's editor instance).
Differential Revision: https://phabricator.services.mozilla.com/D108568
Editor command should be handled in same command table between `ExecCommand`
and the other related methods. However, currently, only `ExecCommand` does
optimized things. For using same logic in the other methods, the code should
be in an independent stack class.
Differential Revision: https://phabricator.services.mozilla.com/D108567
Previously, the DocGroup type was not cycle-collected, as it needed to have
references from other threads for Quantum DOM. Nowadays the only off-main-thread
use of DocGroup is for dispatching runnables to the main thread which should be
tracked using a performance counter for about:performance. This means we can
remove the DocGroup references from these dispatching callsites, only storing
the Performance Counter we're interested in, and simplify make DocGroup be
cycle-collected itself.
This fixes a leak caused by adding the WindowGlobalChild getter to
WindowContext, by allowing cycles between the document and its BrowsingContext
to be broken by the cycle-collector.
Differential Revision: https://phabricator.services.mozilla.com/D108865
According to the source code of Chromium, we should throw exceptions from
them only when the document is not for HTML nor XHTML. For the other reasons,
we should not throw any exceptions even if it's unknown command.
Differential Revision: https://phabricator.services.mozilla.com/D108573
This patch adds two events - `DOMFormRemoved` and `DOMInputPasswordRemoved`.
These events are notified when a form/password field is removed from
the DOM tree. When the LoginManagerChild receives the event, it calls
_onFormSubmit as the form is submitted.
This patch also adds a WeakFieldSet formlessModifiedPasswordFields to
record all the form-less password fields that users have interacted
with to track whether a formless password is removed
Depends on D106024
Differential Revision: https://phabricator.services.mozilla.com/D106025
The goal of this series of patches is to address the cases where sites
don't use standard form submission events.
The basic idea is inferring a form is submitted when the form is removed
from the DOM tree, but with one premise:
There must be a successful fetch or XHR request sent in the document before the
form is removed.
This is because websites usually send the credentials with a fetch or an
XHR. After the request succeeds, the website removes the form.
In summary, this patch does the following:
1. Add NotifyFetchOrXHRSuccess API in Document. The API sends a
"DOMDocFetchSuccess" event to who registers the event listener.
2. When a fetch request or a XMLHttpReuqest completes and succeeds,
call NotifyFetchOrXHRSuccess().
3. LoginMangerChild listen to `DOMDocFetchSuccess` event only when there
is an user interaction on the password field.
Differential Revision: https://phabricator.services.mozilla.com/D106024
We now use BrowsingContext to climb the tree and grab frame elements so
we skip over any OOP ancestors.
`Document::GetBrowsingContext()` may be `null` when the document was
just created with `document.implementation.createDocument`.
`Document::GetWindow()` will also return `null` in this case, so we
assume the document isn't a descendant of the adoptedNode, preserving
the old behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D107584
This seems to match Chrome, and makes our fullscreen implementation more
consistent between desktop and mobile.
Do you know how to best test this? This repros in RDM, but all
fullscreen tests seem disabled on Android...
Differential Revision: https://phabricator.services.mozilla.com/D107365
Use internal events which get fired for CSSOM changes, and in Shadow
DOM. This will also allow us to remove mutation events in the future.
Depends on D106273
Differential Revision: https://phabricator.services.mozilla.com/D106274
Use internal events which get fired for CSSOM changes, and in Shadow
DOM. This will also allow us to remove mutation events in the future.
Depends on D106273
Differential Revision: https://phabricator.services.mozilla.com/D106274
There are quite a few different logging modules for session history, but while developing
SHIP BFCache, I'd prefer to add some specific one for it. Later we can perhaps
merge various modules to some generic session history related.
SHIPBFCache log module will be used more in the followup patches.
Differential Revision: https://phabricator.services.mozilla.com/D105237
There are quite a few different logging modules for session history, but while developing
SHIP BFCache, I'd prefer to add some specific one for it. Later we can perhaps
merge various modules to some generic session history related.
SHIPBFCache log module will be used more in the followup patches.
Differential Revision: https://phabricator.services.mozilla.com/D105237
This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
We don't override any of the methods. I wonder when this stopped being
useful, it seemed useless before bug 1420547 already, and the comment
oes back to bug 342062...
Differential Revision: https://phabricator.services.mozilla.com/D106268
Renaming the function makes it clear that it only deals with in-process ancestors, which is an important distinction for Fission.
A11y is the only consumer of this and it only cares about in-process ancestors in this case (OOP stuff is handled elsewhere), so the functionality doesn't need to change.
Since a11y is the only consumer, move this into the a11y code.
Differential Revision: https://phabricator.services.mozilla.com/D104341
This makes it so that we correctly set nsIGlobalObject::IsInSyncOperation
for in-process descendant frames that have out-of-process ancestors.
Differential Revision: https://phabricator.services.mozilla.com/D102330
We keep mMedium in nsPresContext rather than just looking it up in the
browsing context because that's used quite more frequently.
Differential Revision: https://phabricator.services.mozilla.com/D103782
This is an issue I found while going through this code and
writing/debugging a test for the bug at hand. Without this, the test in
the actual fix for this bug will fail to actually reuse the preloaded
stylesheet.
It seems reasonable to assume that the intersection of quirks mode
documents using link preload headers is small (and in that case we'd
parse the sheet twice, but oh well).
Differential Revision: https://phabricator.services.mozilla.com/D103567
This makes it so that we correctly set nsIGlobalObject::IsInSyncOperation
for in-process descendant frames that have out-of-process ancestors.
Differential Revision: https://phabricator.services.mozilla.com/D102330
Much like devtools manages the existing stylesheet changed events.
This is tested by devtools/client/inspector/markup/test/browser_markup_shadowdom.js
Differential Revision: https://phabricator.services.mozilla.com/D102875
All sets of mVisibilityState go through this function now, and not
having a window implies that the visibility state must be hidden, so
this should be sound now.
I'll land this separately anyway since it's slightly more risky.
Differential Revision: https://phabricator.services.mozilla.com/D41439
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
Implement manifest v3 CSP that is compatible with the current chrome implementation.
Support for content_security_policy.isolated_world (a.k.a. content_security_policy.content_scripts)
has been removed for consistency with
345390adf6%5E%21/
Differential Revision: https://phabricator.services.mozilla.com/D100573
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
