EventStateManager::PostHandleEvent would do the same thing, but need to handle
the cases that PresShell is destroyed and frame is destroyed in
pointerup/pointercancel event listener.
The former case would be handled in D102403. For the latter case, we allow
EventStateManager::PostHandleEvent to handle pointerup/pointercancel event while
frame is no longer available in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D102404
Found a possible leak from running layout/base/tests/test_bug993936.html after
enable implicit pointer capture for touch event. The test synthesize touchstart
and touchmove event, but no touchend, so we don't run the release steps and the
PointerCaptureInfo still hold a reference to Element which cause the leak.
This could also possible happens in real world, for example, user touch a page
with finger that triggers pointer capture, and then tab get closed before touch
is released.
Differential Revision: https://phabricator.services.mozilla.com/D102403
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
Thunderbird loads moz-extension: pages in about:preferences to allow configuration of FileLink extensions. When remote extensions are enabled this will need to be done with a remote browser.
Differential Revision: https://phabricator.services.mozilla.com/D99844
As we can only snapshot a telemetry histogram in the chrome process, we have to make them measurable in the chrome process and write a chrome mochitest.
Differential Revision: https://phabricator.services.mozilla.com/D101266
If we're using null decoder, which generates an empty video frame (0*0), then `VideoInfo::IsValid()` would return false and we're not able to report the telemetry for that video.
Therefore, we should verify that by checking either display or image size to know if we should report the telemetry or not.
Differential Revision: https://phabricator.services.mozilla.com/D101561
In this patch, we move the responsibility of accumulating time and report the telemetry to `TelemetryProbesReporter`.
There are some differences between new telemetry report and the old one.
1. more accuracy on knowing if element is visible
2. more accuracy on determining when it should start accumulating visible & invisible play time
3. being able to report the correct result when element encounts an error or changes to a new resource
4. report result whenever MediaDecoder stops working
Here is the explanation [1] describing why our previous method was not able to achieve those advantages.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1685399#c13
Differential Revision: https://phabricator.services.mozilla.com/D101112
I will move these telemetry related codes out from media element, so I want to avoid using media element's own attribute to determine if we need to report the probe or not, which will help that following works don't need to reply on media element's own attribute.
Differential Revision: https://phabricator.services.mozilla.com/D101109
There is no need for decoder to use both "document visibility" and "element's layout visibility" to determine if we should suspend decoding.
That can simply be done by checking `HTMLMediaElement::IsActuallyInvisible()`.
Differential Revision: https://phabricator.services.mozilla.com/D101108
There are several functions related with an element's visibie state, which are confusing. So this patch is going to make them clearer and remove unnecessary function.
- `IsVisible()` : add description to mention that the visibility state is only for layout level, which doesn't represent the actual visible state.
- rename `IsHidden()` to `IsActualInvisible()` : make it represent the actual visible state of an element.
- remove `IsActive()` : current two callers of `IsActive()` only care about if the page is inactive or not, it doesn't care about if page hidden or not. So we can call the owner doc's method directly.
Differential Revision: https://phabricator.services.mozilla.com/D101107
Otherwise autoplay blocking until-in-foreground breaks with the other
patch in this bug, because it unblocks media playback once a browsing
context is active for the first time.
Differential Revision: https://phabricator.services.mozilla.com/D42329