This patch removes the dispatch of ReportGenericErrorRunnables when
a worker fails to start, since they were causing crashes and
weren't getting run anyway. It also adds an assertion that prevents
the creation of strong references to workers before they begin
their main loop.
Differential Revision: https://phabricator.services.mozilla.com/D76693
In Tor Browser dom.securecontext.whitelist_onions is true by default, so we need a small
patch for tests from bug 1382359 to pass. We would like to upstream that patch, which
is just making sure dom.securecontext.whitelist_onions is false before starting the test.
Differential Revision: https://phabricator.services.mozilla.com/D76726
In the common case of using case sensitive matching, improvements come from:
* for attributes backed by nsStringBuffers, not needing to AddRef/Release the
string buffer
* for attributes backed by atoms, not needing to run the destructor of an
nsDependentAtomString
* for prefix and suffix attribute selectors, using memcmp instead of the
slower StringBeginsWith/StringEndsWith (which read a character at a
time and call a virtual function on the comparator object)
* for the substring attribute selector, using std::search(), which also
avoids virtual function calls on a comparator object
Attribute selector performance is important on pages with many links
with ad blocker extensions that use such selectors installed.
On my machine, this drops total time spent loading the single page HTML
spec
* under Gecko_AttrHasPrefix from 2.69 s to 1.25 s
* under Gecko_AttrHasSubstring from 1.06 s to 0.30 s
Differential Revision: https://phabricator.services.mozilla.com/D76643
IsInNativeAnonymousSubtree and IsRootOfNativeAnonymousSubtree are
exposed in nsINode, so we don't need to make sure to call them on
nsIContent objects.
Depends on D76681
Differential Revision: https://phabricator.services.mozilla.com/D76682
In favor of the NativeAnonymous versions which they forward to.
Done automatically with:
rg -l 'IsInAnonymousSubtree' | xargs sed -i 's/IsInAnonymousSubtree/IsInNativeAnonymousSubtree/g'
And removing the function definitions afterwards.
Differential Revision: https://phabricator.services.mozilla.com/D76681
The only caller that passes that principal is the only caller that calls
into LoadSheet with a loader that has a document anyway.
And the principal we're passing is Document::NodePrincipal(), which is
what we'd end up using anyway, so the new code is exactly equivalent, as
far as I can tell.
Differential Revision: https://phabricator.services.mozilla.com/D76469
Replace ScriptEvaluation profiler marker with compilation & execution markers for bytecode, module, binast, and text sources.
Differential Revision: https://phabricator.services.mozilla.com/D75223
I removed some outlines in gtk which causes some repaints not to show
up. However I think this test should be simplified a bit instead.
When this test landed in bug 426082, snapshots and such were the only
way to test this because it was a widget hack, effectively. Nowadays,
that "forward hover and active state from label to labeled element"
happens at the event state manager level, and thus we can test it much
more easily using simple selector-matching.
Differential Revision: https://phabricator.services.mozilla.com/D76602
This should fix the issue for preallocated processes that still don't
host any document, and also send a few less IPC messages.
Differential Revision: https://phabricator.services.mozilla.com/D76537
Firing eMouseExitFromWidget means we are leaving a specific remote target, then
we should not update sLastMouseRemoteTarget. Otherwise the subsequent event
might trigger sending eMouseExitFromWidget again.
Differential Revision: https://phabricator.services.mozilla.com/D75916
Top-level content WindowGlobalParents now keep track of the site origins of the
documents in their document tree. When the WindowGlobalParent is torn down, the
maximum of the number of unique site origins is submitted for telemetry.
Differential Revision: https://phabricator.services.mozilla.com/D71493
When transitioning visibility and opacity at the same time, we create
two effects, one animating opacity, and one visibility.
We're incorrectly throttling the visibility animation due to opacity,
because _that_ effect is not animating opacity, but the other one is and
thus doesn't get throttled.
Use HasAnimationOfOpacity() to check for this case. This is slightly
sketchy, because the first time we get through there we may not even
have started the opacity animation yet. However it kinda works, because
the fact that there's a (non-throttled, because of the
aEffect.HasOpacityChange()) opacity animation means that we'll tick both
of them, and unthrottle them next frame.
This seems better than the alternative which is never throttling
animations in opacity: 0 roots.
Differential Revision: https://phabricator.services.mozilla.com/D76405
I don't think all this complexity is worth it for having a
marginally-more-realistic testing story. Using the pref just works and we should
do that, I think.
Differential Revision: https://phabricator.services.mozilla.com/D59980
This turned out to be simpler than expected. Apart from generated bindings, a lot of the callers didn't make use of the fact that the return value was a handle.
Differential Revision: https://phabricator.services.mozilla.com/D72120
In order to test its parsing and serialization, we expose it but protect
it behind a pref.
Besides, I would like to drop layout.css.aspect-ratio-number.enabled in
the next patch because the spec has been updated. It seems we don't have
to keep this pref and we should always use Number.
Differential Revision: https://phabricator.services.mozilla.com/D74955
Which is the spec term. nsIStyleSheetLinkingElement is even more
confusing since it may not be an element at all (see: processing
instructions).
Differential Revision: https://phabricator.services.mozilla.com/D76071
I suspect that when enabling Fission, in some situation, we might get a null window context which results in a crash. Therefore, returning a deny action if we are not able to get a window context.
Differential Revision: https://phabricator.services.mozilla.com/D76196
This corrects the handling of user-scalable=no to first clamp scale (whether
specified or default) between min and max scales, then applies the resulting
value to initial-scale, min and max.
Differential Revision: https://phabricator.services.mozilla.com/D76056
This enables navigating by index in session history go through the
session history in the parent (if enabled with the pref).
If the pref is enabled, then ChildSHistory::Go will send an IPC message
to the parent with the index to navigate to. The parent calls the
existing nsSHistory implementation and starts the loads, and
asynchronously returns the index that we actually navigated to. The
child process then uses that result to update the session history
implementation in the child process (this part is temporary, while we
have session history both in parent and in child). We also make the
parent send an updated length to the child process over IPC, so that
history.length always the length for the implementation in the parent.
Differential Revision: https://phabricator.services.mozilla.com/D65330
This adds a new implementation of nsISHEntry
(mozilla::dom::SessionHistoryEntry). When session history in the parent
is turned on, we'll instantiate the existing nsSHistory in the parent
process, but it will store entries of this new type. The nsSHistory in
the child process will also be instantiated for now, to avoid breaking
too many assumptions, and we try to keep parent and child
implementations in sync.
mozilla::dom::SessionHistoryEntry stores most of its data in a new
structure (mozilla::dom::SessionHistoryInfo) which can be sent over IPC.
When a load starts through the DocumentChannel we create an entry of
this new type for it in the parent process in
DocumentLoadListener::Open. The SessionHistoryInfo for that entry (with
an associated ID) is then sent over IPC in the RedirectToRealChannelArgs
to the process that does the actual load, where we store it in the
nsDocShell in mLoadingEntry (and mLoadingEntryId). The parent process
keeps track of outstanding loading entries in an array (mLoadingEntries)
in the CanonicalBrowsingContext. When a load finishes the nsDocShell
transfers mLoadingEntry into mActiveEntry, and notifies the parent
process through an IPC message (HistoryCommit) with the id of that
entry. The CanonicalBrowsingContext then removes the entry from the
array and stores it in its mActiveEntry, and adds the entry to the
nsSHistory object.
There are a number of things in this patch that are broken, and a lot of
FIXME comments. However, with the pref turned off things should just be
working as before. The goal is to land this first part, and then iterate
on the new implementation until we can switch over.
Differential Revision: https://phabricator.services.mozilla.com/D65329
Removed "media.navigator.audio.full_duplex" pref
It was related to `MediaEnginePrefs::mFullDuplex` which wasn't used too, so the according code has been removed
Differential Revision: https://phabricator.services.mozilla.com/D75993
This patch makes the triggering princpal to be propagated to the
BrowserChild when calling LoadURL in nsFrameLoader. And use it as the
triggering principal for loading instead of the system principal.
Differential Revision: https://phabricator.services.mozilla.com/D75965
The ability to reverse axes internally was added in bug 983427, but it
turns out not to be used.
test_flex_lines.html needs to be modified because those expected cross
values are written as if the flex lines are physically in top-to-bottom
order (due to we reversed the axes internally).
Now we don't reverse the internal axes, the order of the flex lines
becomes bottom-to-top due to "flex-wrap: wrap-reverse". The crossStart
coordinate begins from the flex container's bottom end edge, and it
increases from bottom to the top to the flex container's top end
edge. (Note the flex container has 42px height.)
Differential Revision: https://phabricator.services.mozilla.com/D75887
This patch will do :
- add `MOZ_DIAGNOSTIC_ASSERT` to ensure the sample is valid to be accessed
The advantage :
- to ensure the sample is still valid when we push it to the queue or pop it out the queue
Differential Revision: https://phabricator.services.mozilla.com/D75871
Currently, the worker's COEP is saved in WorkerPrivate and not be respected when loading resources in workers.
This patch adds an attribute loadingEmbedderPolicy in nsILoadInfo, which indicates the COEP header the loading must be respected.
The default value of loadingEmbedderPolicy is nsILoadInfo::EMBEDDER_POLICY_NULL.
loadingEmbedderPolicy is initialized with the COEP of the BrowsingContext used for creating LoadInfo.
And it could be set to other value when fetch in workers.
Differential Revision: https://phabricator.services.mozilla.com/D73690
Currently, the worker's COEP value is saved in WorkerPrivate and it is not respected for fetch/cache API in workers.
This patch saving the COEP value which fetch/cache API should be respected when using in workers.
Notice that for the dedicated workers, it is not only respected to worker's COEP but also its owner's.
For fetch in workers, P2 will propagate the COEP value through nsILoadInfo to HttpChannels, such that COEP can be respected in parent process when calling ProcessCrossOriginResourcePolicyHeader() and ProcessCrossOriginEmbedderPolicyHeader().
For cache in workers. We handle it in bug 1603168. COEP will be propagated through CacheRequest to the parent process and respected in CacheOpParent::OnOpComplete().
Differential Revision: https://phabricator.services.mozilla.com/D73689
During the last cycle collection, state watchers may attempt to dispatch tasks to the current AbstractThread, so we can't clear the TLS entry until that step has completed.
We want the object to be deleted last; ordering in call to ClearOnShutdown() can't guarantee it.
Differential Revision: https://phabricator.services.mozilla.com/D75498
We already have an architecture to sync the storage access granted
result to all 3rd-party frames with the same tracking origin.
We use the same way to sync HasStorageAccess flag instead of relying
on permission manager update permissions to child processes.
Differential Revision: https://phabricator.services.mozilla.com/D73711
Before this patch, we only call StorageAccessGranted on windows that
triggers the storage heuristics. So even if we sync storage permission to the
other frames, their data will not be refreshed. For example, if a document
has a worker, we don't propagate the permission to the worker.
In this patch, we call ::StorageAccessGranted as long as we update
the window's storage permission.
Differential Revision: https://phabricator.services.mozilla.com/D74321
Before this patch, in non-fission mode, we cache storage access granted result
in the top-level window so we don't have to iterate all the browsing contexts
in the same tree while syncing the storage permission granted decision.
However, since we plan to rely on the current update mechanism to sync
mHasStorageAccess flag for different documents in the same tab (instead of using
the syncing mechanism of permission manager), we will eventually need to iterate
the browsing context tree to find all the documents to sync. Base on this,
we no longer have to maintain different method for fission and non-fission.
In this patch, we store the permission granted result in the inner
window instead of using permission key and store the key in the top-level
window.
Differential Revision: https://phabricator.services.mozilla.com/D73710
The UITour code assumes that it will return the up-to-date value, which
doesn't happen with lazy frame construction.
This is used sparingly in the front end code, so it doesn't quite
warrant more optimization.
Differential Revision: https://phabricator.services.mozilla.com/D75710
The Mac focus model is a bit different (mouse doesn't focus form
controls for example).
This matches GTK3 to my knowledge, where outlines are not shown until
you've navigated with the keyboard.
We should maybe consider changing Android as well (and maybe all
platforms, actually), but that's a bit of a bigger endeavour.
Differential Revision: https://phabricator.services.mozilla.com/D75505
We already have an architecture to sync the storage access granted
result to all 3rd-party frames with the same tracking origin.
We use the same way to sync HasStorageAccess flag instead of relying
on permission manager update permissions to child processes.
Differential Revision: https://phabricator.services.mozilla.com/D73711
Before this patch, we only call StorageAccessGranted on windows that
triggers the storage heuristics. So even if we sync storage permission to the
other frames, their data will not be refreshed. For example, if a document
has a worker, we don't propagate the permission to the worker.
In this patch, we call ::StorageAccessGranted as long as we update
the window's storage permission.
Differential Revision: https://phabricator.services.mozilla.com/D74321
Before this patch, in non-fission mode, we cache storage access granted result
in the top-level window so we don't have to iterate all the browsing contexts
in the same tree while syncing the storage permission granted decision.
However, since we plan to rely on the current update mechanism to sync
mHasStorageAccess flag for different documents in the same tab (instead of using
the syncing mechanism of permission manager), we will eventually need to iterate
the browsing context tree to find all the documents to sync. Base on this,
we no longer have to maintain different method for fission and non-fission.
In this patch, we store the permission granted result in the inner
window instead of using permission key and store the key in the top-level
window.
Differential Revision: https://phabricator.services.mozilla.com/D73710
Using StaticRefPtr instead of a raw pointer for sSharedWorkerService in SharedWorkerService.cpp, and keeping sSharedWorkerService be alive until shutdown by registering sSharedWorkerService to ClearOnShutdown.
Since sSharedWorkerService is not raw pointer anymore, SharedWorkerService needs not to inherit from SupportsCheckedUnsafePtr<CheckIf<DiagnosticAssertEnabled>>
Differential Revision: https://phabricator.services.mozilla.com/D72379
The patch also removes the ignoreRootScrollFrame option from
APZCCallbackHelper::DispatchMouseEvent() altogether as it is
no longer used.
Depends on D75735
Differential Revision: https://phabricator.services.mozilla.com/D75736
This patch will do :
- use `MediaSampleMarkerPayload` to replace `VideoFrameMarkerPayload`
The advantage of doing so :
- after finishing a support for `MediaSampleMarkerPayload` in profiler front-end side, we can show the sample's start and end time when hovering on the marker icon.
Differential Revision: https://phabricator.services.mozilla.com/D75469
This patch will do :
- add `Media` markers in related codes
- implement `MediaSampleMarkerPayload` to record the media sample
The advantage of doing so :
- using markers can help us know what happens on the media by a glance without expanding the call stack
- adding sample markers allows us compare the speed of decoding sample in `MediaDecoderStataMachine` and rendering sample in `VideoSink`
Differential Revision: https://phabricator.services.mozilla.com/D74174
This patch will do :
- create a sub-category `Cubeb`
- add `Cubeb` profiling labels in related codes
The advantage of doing so :
- allow us to know the percentage of time respectively we spend on cubeb and non-cubeb codes
More details :
The profiling code would include `<atomic>` which is C++ only, so I can't use the label in `cubeb.c` directly. Instead, I add labels on the `AudioStream` and `AudioCallbackDriver` where we would call cubeb related methods.
Differential Revision: https://phabricator.services.mozilla.com/D74172
This patch will do :
- create a profiling category `Media`
- add `Media` profiling labels in related codes
The advantage of doing so :
- allow us to easily see what operations are related to media playback from the profiled report
More details :
According to the description in the `ProfilingCategory.h`, `topmost profiler label frame in the label stack determines the category pair of that stack`. Therefore, most labels I added are the first task would run on the thread, in order to ensure all its following tasks can be marked as the media playback label as well.
Differential Revision: https://phabricator.services.mozilla.com/D74171
Instead move the check to the focus manager, more similar to how
focus-visible works.
Now nsGlobalWindowInner::ShouldShowFocusRing means "Should we show focus
ring for anything in this window", that is: Have we keyboard-navigated
in this window, or do we have a pref that says that we should always
show focus rings.
Fix some callers appropriately (some of them that were not properly
accounting for the element being focused in the first place...).
Differential Revision: https://phabricator.services.mozilla.com/D75504
ChromeUtils::requestProcInfo was dropping thread names for the process process. This patch restores them and tests that at least *one* thread is named. Unfortunately, at the time of this writing, we cannot assume that *all*
threads are named. Investigation pending.
Differential Revision: https://phabricator.services.mozilla.com/D75420
This patch will do :
- update the media status when media changes its owner browsing context
The advantage of doing so :
- make the media status in `ContextMediaInfo` correcly
More details :
`ContextMediaInfo` stores the media status of each browsing context, but actually the media doesn't always need to stay in one browsing context. We can move it to other browsing contexts (iframe) by appending it to other browsing context's document body.
For example, in [1], we move the video from the main frame to another iframe.
Therefore, when we move the media to a new browsing context, we should also update its media status (controlledMedia/playing/audio number) for its previous owner browsing context.
[1] https://searchfox.org/mozilla-central/source/testing/web-platform/tests/html/semantics/embedded-content/media-elements/playing-the-media-resource/pause-move-to-other-document.html
Differential Revision: https://phabricator.services.mozilla.com/D75477
This patch will do :
- remove audible check from the logic of registering controller
- include audio channel affect on the media element's audible state
The advantage of doing so :
- it can help to reduce the intermittent failure during testing by earlier hooking media elements in the content process to the media controller in the chrome process
More details :
In D72497, we have added the audible check to postpone the activation of the media controller, which would ensure that we only control media after it become audible. Therefore, we can remove the previous implementation which we use to achieve that in media element.
When having that audible check in media element, it would postpone the timing of adding media element to `ContentMediaController` that causes some intermitent failures when I was writing test for bug1633565. When removing those checks, we can ensure that the media element would have always been added into `ContentMediaController` after calling `video.play()`. If the element haven't been added into `ContentMediaController`, then it would miss to handle the media key events when test generates a fake media key event, which causes an intermitent failure.
Differential Revision: https://phabricator.services.mozilla.com/D73335
This patch will do :
- add test cases
- introduce the test-only notification `media-displayed-metadata-changed` when the event source updates its metadata
The advantage of doing so :
- increase test coverage
Differential Revision: https://phabricator.services.mozilla.com/D72501
This patch will do :
- play media from different frame, rather than alway playing media from the main frame
The advantage of doing so :
- to make the media session in child frame become the active media session because that can only be the context with the audio focus
Differential Revision: https://phabricator.services.mozilla.com/D72500
This patch will do :
- remove out-of-date test that uses the previous implementation of determining the active media session
The advantage of doing so :
- prevent the failure causing by out-of-date test
Differential Revision: https://phabricator.services.mozilla.com/D72499
This patch will do :
- listen to the playback change from the event source directly
The advantage of doing so :
- more close to the real situation because the event source is where we decide the information that should be displayed the virtual control interface
Differential Revision: https://phabricator.services.mozilla.com/D72498
This patch will do :
- postpone the timing of activating the media controller. Activate the controller after it first time becomes audible.
The advantage of doing so :
- prevent setting incorrect media metadata before the controller becomes audible
---
More details about this change :
The active media session would be chose after the context owns the audio focus. Therefore, if we would like to get the correct metadata from the media session, we should postpone the timimg of activate controller and wait until we decide the active media session then we can get the correct metadata.
Differential Revision: https://phabricator.services.mozilla.com/D72497
This patch will do :
- using the audio focus to decide which media session is the active media session. That is a recommend way of the spec [1].
The advantage of doing so :
- prevent to routing media control keys to incorrect media session
- prevent showing the incorrect metadata on the virtual control interface
[1] https://w3c.github.io/mediasession/#active-media-session
Differential Revision: https://phabricator.services.mozilla.com/D72496
This patch will do :
- introduce a concept `audio focus` among different contexts within a tab
- determine the audio focus owner when the context becomes audible or the owner destroys
The advantage of doing so :
- the audio focus helps us to decide the active media session that would be implemented in the following part
More details:
When there are serveral contexts playing at the same time within a tab, we would like to determine an audible context from them to represent the tab, and that is the `audio focus` we mean in this bug.
Differential Revision: https://phabricator.services.mozilla.com/D72495
This patch will do :
- replace the usage of `nsIDocShellTreeItem` with accessing the permission stored in the `WindowContext`
The advantage of doing so :
- determine the correct result for the blocking autoplay because `nsIDocShellTreeItem` is not always possible to be accessed after we enable Fission
More details :
When determining the result of the blocking autoplay, we would always check if the page is in user customized whitelist or blacklist in which we store sites domain, and the domain we check is always the top level window's domain.
For example, a page (foo.com) has an iframe (bar.com), and we allow `foo.com` to autoplay. Then, if the iframe `bar.com` wants to autoplay from this page, we would also allow it because the main page is `foo.com`.
However, the current way of checking `nsIDocShellTreeItem` is not Fission compatible, because you can't access `nsIDocShellTreeItem` in the different process if the iframe is cross-origin. Therefore, we should remove its usage.
Differential Revision: https://phabricator.services.mozilla.com/D74512
This patch will do :
- create a sync field `AutoplayPermission` on WindowContext
- update the field whenever site's the autoplay permission changes
The advantage of doing so :
- to help determine the result of the blocking autoplay correctly.
More details :
As the field would be automatically synced between processes, then we can know the correct site's autoplay permission for the whole page even if we're in the different process if the iframe is in different origin after we enable Fission.
Differential Revision: https://phabricator.services.mozilla.com/D74511
This patch will do :
- update the media status when media changes its owner browsing context
The advantage of doing so :
- make the media status in `ContextMediaInfo` correcly
More details :
`ContextMediaInfo` stores the media status of each browsing context, but actually the media doesn't always need to stay in one browsing context. We can move it to other browsing contexts (iframe) by appending it to other browsing context's document body.
For example, in [1], we move the video from the main frame to another iframe.
Therefore, when we move the media to a new browsing context, we should also update its media status (controlledMedia/playing/audio number) for its previous owner browsing context.
[1] https://searchfox.org/mozilla-central/source/testing/web-platform/tests/html/semantics/embedded-content/media-elements/playing-the-media-resource/pause-move-to-other-document.html
Differential Revision: https://phabricator.services.mozilla.com/D75477
This patch will do :
- remove audible check from the logic of registering controller
- include audio channel affect on the media element's audible state
The advantage of doing so :
- it can help to reduce the intermittent failure during testing by earlier hooking media elements in the content process to the media controller in the chrome process
More details :
In D72497, we have added the audible check to postpone the activation of the media controller, which would ensure that we only control media after it become audible. Therefore, we can remove the previous implementation which we use to achieve that in media element.
When having that audible check in media element, it would postpone the timing of adding media element to `ContentMediaController` that causes some intermitent failures when I was writing test for bug1633565. When removing those checks, we can ensure that the media element would have always been added into `ContentMediaController` after calling `video.play()`. If the element haven't been added into `ContentMediaController`, then it would miss to handle the media key events when test generates a fake media key event, which causes an intermitent failure.
Differential Revision: https://phabricator.services.mozilla.com/D73335
This patch will do :
- add test cases
- introduce the test-only notification `media-displayed-metadata-changed` when the event source updates its metadata
The advantage of doing so :
- increase test coverage
Differential Revision: https://phabricator.services.mozilla.com/D72501
This patch will do :
- play media from different frame, rather than alway playing media from the main frame
The advantage of doing so :
- to make the media session in child frame become the active media session because that can only be the context with the audio focus
Differential Revision: https://phabricator.services.mozilla.com/D72500
This patch will do :
- remove out-of-date test that uses the previous implementation of determining the active media session
The advantage of doing so :
- prevent the failure causing by out-of-date test
Differential Revision: https://phabricator.services.mozilla.com/D72499
This patch will do :
- listen to the playback change from the event source directly
The advantage of doing so :
- more close to the real situation because the event source is where we decide the information that should be displayed the virtual control interface
Differential Revision: https://phabricator.services.mozilla.com/D72498
This patch will do :
- postpone the timing of activating the media controller. Activate the controller after it first time becomes audible.
The advantage of doing so :
- prevent setting incorrect media metadata before the controller becomes audible
---
More details about this change :
The active media session would be chose after the context owns the audio focus. Therefore, if we would like to get the correct metadata from the media session, we should postpone the timimg of activate controller and wait until we decide the active media session then we can get the correct metadata.
Differential Revision: https://phabricator.services.mozilla.com/D72497
This patch will do :
- using the audio focus to decide which media session is the active media session. That is a recommend way of the spec [1].
The advantage of doing so :
- prevent to routing media control keys to incorrect media session
- prevent showing the incorrect metadata on the virtual control interface
[1] https://w3c.github.io/mediasession/#active-media-session
Differential Revision: https://phabricator.services.mozilla.com/D72496
This patch will do :
- introduce a concept `audio focus` among different contexts within a tab
- determine the audio focus owner when the context becomes audible or the owner destroys
The advantage of doing so :
- the audio focus helps us to decide the active media session that would be implemented in the following part
More details:
When there are serveral contexts playing at the same time within a tab, we would like to determine an audible context from them to represent the tab, and that is the `audio focus` we mean in this bug.
Differential Revision: https://phabricator.services.mozilla.com/D72495
Instead move the check to the focus manager, more similar to how
focus-visible works.
Now nsGlobalWindowInner::ShouldShowFocusRing means "Should we show focus
ring for anything in this window", that is: Have we keyboard-navigated
in this window, or do we have a pref that says that we should always
show focus rings.
Fix some callers appropriately (some of them that were not properly
accounting for the element being focused in the first place...).
Differential Revision: https://phabricator.services.mozilla.com/D75504
In this bug we're moving away from monolithic JNI headers to class-specific
headers so that we don't have to rebuild the world every time we make a change
to a JNI interface.
Differential Revision: https://phabricator.services.mozilla.com/D75380
In this bug we're moving away from monolithic JNI headers to class-specific
headers so that we don't have to rebuild the world every time we make a change
to a JNI interface.
Differential Revision: https://phabricator.services.mozilla.com/D75378
In this bug we're moving away from monolithic JNI headers to class-specific
headers so that we don't have to rebuild the world every time we make a change
to a JNI interface.
Differential Revision: https://phabricator.services.mozilla.com/D75374
In this bug we're moving away from monolithic JNI headers to class-specific
headers so that we don't have to rebuild the world every time we make a change
to a JNI interface.
Differential Revision: https://phabricator.services.mozilla.com/D75373
We do this by keeping the unexpected frame in mReorderQueue, and outputting it later when the caller is expecting frames.
Differential Revision: https://phabricator.services.mozilla.com/D75116
ChromeUtils::requestProcInfo was dropping thread names for the process process. This patch restores them and tests that at least *one* thread is named. Unfortunately, at the time of this writing, we cannot assume that *all*
threads are named. Investigation pending.
Differential Revision: https://phabricator.services.mozilla.com/D75420
DestroyMediaTrack() is called only on Unlink or destruction of the AudioDestinationNode.
If there are no references to the AudioDestinationNode, then the graph's last stream
will be destroyed and the graph will shut down itself.
Differential Revision: https://phabricator.services.mozilla.com/D74812
This patch will do :
- replace the old pref with the new pref
The advantage of doing so :
- to ensure those tests can still use the correct blocking autoplay policy
Differential Revision: https://phabricator.services.mozilla.com/D73973
This patch will do :
- rename the old pref `media.autoplay.enabled.user-gestures-needed` to the new pref `media.autoplay.blocking_policy`
- modify the value of the pref to `int` in order to introduce new policy
- implement new policy in `AutoplayPoliocy`
The advantage of doing so :
- rename the pref to explicitly indicate that it's related the block policy we use
- use the transient user gesture activation as a new policy to replace the old one using the user input, which doesn't work on the async handler
More details :
The old `click-to-play` policy we use is using the user input to determine if the play invocation is called by users or by scripts. But `UserActivation::IsHandlingUserInput()` is buggy which would fail when you call `video.play()` inside an async event handler. So we would like to replace it with the new transient user activation, which would treat the action as an user input if the action is performed within a certain period of time after a user interacts (eg. click) with the page.
[1] https://html.spec.whatwg.org/multipage/interaction.html#transient-activation
Differential Revision: https://phabricator.services.mozilla.com/D73971
This also requires changing the EffectCompositor to allow animations in print
and print preview, and setting up a document timeline for the cloned document
Differential Revision: https://phabricator.services.mozilla.com/D69069
This patch will do :
- replace the old pref with the new pref
The advantage of doing so :
- to ensure those tests can still use the correct blocking autoplay policy
Differential Revision: https://phabricator.services.mozilla.com/D73973
This patch will do :
- rename the old pref `media.autoplay.enabled.user-gestures-needed` to the new pref `media.autoplay.blocking_policy`
- modify the value of the pref to `int` in order to introduce new policy
- implement new policy in `AutoplayPoliocy`
The advantage of doing so :
- rename the pref to explicitly indicate that it's related the block policy we use
- use the transient user gesture activation as a new policy to replace the old one using the user input, which doesn't work on the async handler
More details :
The old `click-to-play` policy we use is using the user input to determine if the play invocation is called by users or by scripts. But `UserActivation::IsHandlingUserInput()` is buggy which would fail when you call `video.play()` inside an async event handler. So we would like to replace it with the new transient user activation, which would treat the action as an user input if the action is performed within a certain period of time after a user interacts (eg. click) with the page.
[1] https://html.spec.whatwg.org/multipage/interaction.html#transient-activation
Differential Revision: https://phabricator.services.mozilla.com/D73971
Without limitation, when playing at fast rate the prerolling state could
prevent playback from starting before the codec exhausts all buffers. Set
a cap value so the state machine can exit prerolling state before queuing
too many buffers.
Differential Revision: https://phabricator.services.mozilla.com/D75174
In WebVR we call WebGLContext::ClearVRFrame when the presentation ends. We didn't have the equivalent call in WebXR. It helps to reduce memory usage earlier when exiting WebXR and reduces potential deadlocks if the ExternalVR client didn't call SurfaceTexture->ReleaseTexImage() correctly.
Differential Revision: https://phabricator.services.mozilla.com/D75417
mForceShutDown is set on the graph thread and so can be safely read
once the graph has handed control to the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D75239
This method can be and is used by derived classes as well as DOMEventTargetHelper
itself, so it does not need to be "Internal".
Differential Revision: https://phabricator.services.mozilla.com/D75246
WorkerGlobalScopeBase has no override for `BindToOwner()`, so there is no need
for the virtual call.
The DOMEventTargetHelper(nsIGlobalObject*) constructor is not suitable here
because the nsIGlobalObject would not have been constructed when the
DOMEventTargetHelper constructor would need it.
Depends on D75037
Differential Revision: https://phabricator.services.mozilla.com/D75039
Get all the statistics in one call, under the same mutex, and extract from them the decoded and total frames. The individual getters were previously used, created uncertainty since they lock the mutex separately.
Differential Revision: https://phabricator.services.mozilla.com/D75096
For now, only test_listOrigins.js, test_originWithCaret.js and test_simpledb.js
can run in a child process because they don't need to set preferences or access
files in the profile directory.
We will be able to run more tests in a child process once we have SpecialPowers
for xpcshell implemented using JSProcessActors and when we expose the base
directory used by QuotaManager through a new QuotaManagerService method (to
avoid getting the profile directory using nsIDirectoryService because that
doesn't work in a child process).
Differential Revision: https://phabricator.services.mozilla.com/D75281