Firefox and Chrome support setting `src` with an `ObjectURL`. This is
technically a URL and should be treated as such. Firefox recently changed to
return `""` when a `MediaSource` is playing, and this is wrong, because even
though it's playing a from a "Media Provider Object", it got loaded from the
`src` attribute, so should have a non-null `currentSrc`, which should be the
blob url (`blob:origin/<an uuid>`). In this case, `currentSrc` is a string that
is opaque and doesn't allow introspection but refers to the "real" `MediaSource`
or `Blob`.
If the same `MediaSource` is loaded via the `srcObject` attribute (that Firefox
and Chrome don't support), then `currentSrc` should return `""` and `srcObject`
still has the object set to it to understand what the HTMLMediaElement is
playing. We'll implement and test this later.
Differential Revision: https://phabricator.services.mozilla.com/D110290
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
Add test cases for `DecoderDoctorDiagnostics::StoreFormatDiagnostics()`, which is used when checking the ability of whether the decoder is supported for certain type.
Differential Revision: https://phabricator.services.mozilla.com/D104475
Add test cases for `DecoderDoctorDiagnostics::StoreFormatDiagnostics()`, which is used when checking the ability of whether the decoder is supported for certain type.
Differential Revision: https://phabricator.services.mozilla.com/D104475
Roughly:
- Don't reset on load
- Don't reset on URL parsing error
- Reset when playing a MediaStream, a MediaSource
- Otherwise follow the resource selection algorithm, and set it to what has been selected
Differential Revision: https://phabricator.services.mozilla.com/D101937
`nsSyncSection` is not related with media event, so that's not proper ot put it in `MediaElementEventRunners.h`.
In addition, that can simply be implemented by `NS_NewRunnableFunction` so we don't need `nsSyncSection` anymore.
Differential Revision: https://phabricator.services.mozilla.com/D104115
Inplemented an event runner for `timeupdate` only, which would ensure that for periodic `timeupdate` it should be only dispatched once within 250ms.
Differential Revision: https://phabricator.services.mozilla.com/D102675
In this patch, we move all event runners to a separate file and implement an event blocker.
In order to allow us to do a special check for `timeupdate` event, we have to know that event is periodic or mandatory.
We have to save extra information for `timeupdate, however, current design for storing pending events is not flexible enough to achieve that.
Therefore, instead of storing the event name, we store the event runners which can all have different implementation and know when they should dispatch their own event.
Differential Revision: https://phabricator.services.mozilla.com/D102673
`nsSyncSection` is not related with media event, so that's not proper ot put it in `MediaElementEventRunners.h`.
In addition, that can simply be implemented by `NS_NewRunnableFunction` so we don't need `nsSyncSection` anymore.
Differential Revision: https://phabricator.services.mozilla.com/D104115
Inplemented an event runner for `timeupdate` only, which would ensure that for periodic `timeupdate` it should be only dispatched once within 250ms.
Differential Revision: https://phabricator.services.mozilla.com/D102675
In this patch, we move all event runners to a separate file and implement an event blocker.
In order to allow us to do a special check for `timeupdate` event, we have to know that event is periodic or mandatory.
We have to save extra information for `timeupdate, however, current design for storing pending events is not flexible enough to achieve that.
Therefore, instead of storing the event name, we store the event runners which can all have different implementation and know when they should dispatch their own event.
Differential Revision: https://phabricator.services.mozilla.com/D102673
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
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
Changing the tracks-captured state will trigger another run of
UpdateOutputTrackSources, so continuing the current one is futile. The next run
will properly re-evaluate all input state to this function.
Differential Revision: https://phabricator.services.mozilla.com/D100004
When enabling our MediaTrack implementation (which we don't plan to by default,
NB) and disabling all audio tracks and unselecting all video tracks while having
an active captureStream leads to having no output tracks in DecodedStream.
In this case, DecodedStream doesn't know which graph to use for creating the
intermediary tracks it feeds data to. We don't want to resort to the default
graph either, since two graphs on different clocks could then race each other.
With this patch we plumb down a SharedDummyTrack from the media element where
the captureStream was triggered, through MediaDecoder, to DecodedStream. The
SharedDummyTrack guarantees to keep the graph alive, and holds the graph used
for the output tracks.
Differential Revision: https://phabricator.services.mozilla.com/D99822
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
