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 :
- set the value of the new pref based on the value of the old pref
The advantage of doing so :
- ensure that the value of the pref can be transformed correctly
Differential Revision: https://phabricator.services.mozilla.com/D73972
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 destroy the mVRScreen after presentation is exited by calling WebGLContext::ClearVRFrame(). We found that when having multiple windows with active WebGL contexts in Firefox Reality, the WebGL context dies a lot, and you have to reload the page to recover from it. The problem is that when the GLScreenBuffer is destroyed the EGLContext still keeps a reference to the destroyed surface, set by gl->SetEGLSurfaceOverride(surface), which can break the future eglMakeCurrent calls.
Differential Revision: https://phabricator.services.mozilla.com/D75413
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
1/ add tile_cache to input path if frame00000 can't be found
2/ add visual IDs to each tile
3/ hiding a slice also hides its Invalidation info
4/ code cleanup (+= instead of push_str)
Differential Revision: https://phabricator.services.mozilla.com/D75432
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
Inspecting pages with many CSS variables makes DevTools Inspector very slow.
For example, try to inspect an element on [youtube.com](https://www.youtube.com/).
One of the stylesheets loaded by youtube.com contains more than 7800 CSS rules (it's 55K lines long). Some of them specify a very large number of CSS variable delcarations on `:root` which will be inherited by all nodes on the page. This is a perf bottleneck for DevTools.
{F2150398}
Whenever an element is selected, its matching CSS declarations show in the Rules view. If the node inherits CSS variables, for **each declaration**, the Rules view checks if the [variables apply to the current declaration](https://searchfox.org/mozilla-central/rev/2bfe3415fb3a2fba9b1c694bc0b376365e086927/devtools/client/inspector/rules/models/element-style.js#403-408,417,424).
This among other expensive operations which are repeated for each declaration. But for CSS variables, it's particularly slow given the frequent [checks with a regular expression](https://searchfox.org/mozilla-central/rev/2bfe3415fb3a2fba9b1c694bc0b376365e086927/devtools/client/inspector/rules/utils/utils.js#292-295) to verify if a CSS declaration's value includes any references to a given CSS variable name.
This patch introduces new functionality. When a `TextProperty` (aka CSS declaration model) is created on the client, the names of CSS variables found in its value are extracted ahead of time into a `Set`. Whenever we want to check if the declaration uses a certain CSS variable name, we check against this pre-compiled list instead of verifying the string value every time. For high volume checks, like the ones done by the `ElementStyle`, this approach proves significantly faster.
Profile without this patch: https://bit.ly/2Yd7khD
Profile with this patch: https://bit.ly/3aMhJTZ
There are still many optimizations that can be done, but the `hasCSSVariable()` method is no longer a performance bottleneck.
Differential Revision: https://phabricator.services.mozilla.com/D73062
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