We don't want to stop the loading process even we canceled the play operation.
MozReview-Commit-ID: FyPqBlDKYo0
--HG--
extra : rebase_source : fdbc4390a7763bdbe26e8b809d977234bb5360ea
The old way is to start playing first, and then block the media element. This
way is too complicated because it involves lots of interal state and isn't intuitive.
The new way is to ignore the play if the media element should be blocked. It's
easy to know and we doesn't need to keep any internal states because we don't play
the media element.
MozReview-Commit-ID: B20e0pvXES4
--HG--
extra : rebase_source : 6bff5447783c2997050e5c69884afe2c85ddf382
Since the agent is created in beginning in patch1, we need another way to know
whether we have already called notifyStartedPlaying().
MozReview-Commit-ID: 5YNhwEl5Xfp
--HG--
extra : rebase_source : 6a2913e5d81591faf1a7383d9fcb9db2cf3f83d3
We create audio channel agent in the beginning in oreder to use some agent's methods.
But the agent is still started after media element starting playing.
MozReview-Commit-ID: KPGb7snB2t7
--HG--
extra : rebase_source : dba4b687f572d520481721f48a0b4e9796f73e1f
It needs an extra guard for when we're an audio element and a live video track
was removed. That's ok and we should ignore it.
MozReview-Commit-ID: FVw3lDKd4oU
--HG--
extra : rebase_source : 3156abdcd5c57932e8edb61e78ffb568e4edbf2a
Because the agent's initialization might fail if we don't get the valid inner window, we need to
check whether the agent exists before calling the agent's method.
MozReview-Commit-ID: IUuvyGh7CMd
--HG--
extra : rebase_source : 54d0811aad736abdbac5ae7c3cd8cfebed88923a
Because audio channel agent uses weak ref to HTMLMediaElement, so we don't need to add it into the CC list.
MozReview-Commit-ID: 4cFfDUlbMFB
--HG--
extra : rebase_source : 4d595397d11e2e3c46cce17df148bea8f77f92e8
They are not unstoppable any longer. We just don't forward Stop() to the real source.
MozReview-Commit-ID: FdFccMsD3eb
--HG--
extra : rebase_source : e29a1abb8f2060cb72399d61d91ca3a00128f08c
MediaStreamTrack.remote is no longer part of the spec.
MozReview-Commit-ID: BgHJ1zNIoWN
--HG--
extra : rebase_source : 11022eb420cbdb0c7aa5aa7814cf35330f4170b9
This makes sense because the result of StreamListener::NextFrameStatus depends
on mElement.
MozReview-Commit-ID: 8W7nGLpRxE1
--HG--
extra : rebase_source : 48f9c3c637eb01430446dbaf683e65008df19147
Better semantics for what I want to do with NotifyEnded in later patches in the bug.
MozReview-Commit-ID: 8X0BdiVncNo
--HG--
extra : rebase_source : f36f5a17f2294c6ad9b5db2593b41eb8cd8a9a15
This changeset relaxes the shutting down of decoders and removal of mediakeys
when suspending HTMLMediaElements. This should now only happen for adobe
primetime. This alleviates, for non-primetime CDMs, the issue of videos
breaking when moving an EME protected video from a tab to a new window.
These conditions can be relaxed as neither clearkey or widevine support
secure stop. This means we don't need to shutdown their decoders and keys to
signal a stoppage, as at this stage, doing so doesn't give us secure stop and
instead means that playback is busted when we try to resume.
MozReview-Commit-ID: 3MGNXGGDVLS
--HG--
extra : rebase_source : a13fd5fa570a6868af6c3ed7b3dbfab173a9ffef
Otherwise, when a value="" attribute with a newline in it is copied, we
will strip any newlines even if type="hidden" is set, because type=""
hasn't yet been copied. Other bugs are likely too. This problem was
already solved for the parser, so we can just use that solution for
cloning too.
MozReview-Commit-ID: KqxCnxmxFXp
--HG--
extra : rebase_source : 9a666adad3dbbbaa5e3706747dcf70801b9ef4e8
The spec used to say that getting the .ping property on
HTMLAnchorElement or HTMLAreaElement should return a DOMTokenList of
parsed URLs, but it now says to return a plain string. All other UAs
that implement ping match the new spec, and it's hopefully unlikely that
any sites depend on our old behavior.
Discussion: https://github.com/whatwg/html/issues/1780
MozReview-Commit-ID: LpmH8ANNT9g
--HG--
extra : rebase_source : 117021a026d7a1716fa7a705e9417797297697ab
The specification doesn't require there to be a 'type' member of
the keyids init data format.
MozReview-Commit-ID: 7mOm7KwyyuC
--HG--
extra : source : c9fb674f3cb8dff4fe8734e0426e67825878015d
Under some circumstances, we will go from NEXT_FRAME_AVAILABLE to NEXT_FRAME_UNAVAILABLE_BUFFERING directly. We handle this condition now
MozReview-Commit-ID: JVAQhsgzSp2
--HG--
extra : rebase_source : e615e17d49bd35ecb9cb7db84501489ec5e12903
We uses "media-playback" event to notify fennec media control about media start
and end. However, if we resume media which was paused by media control, it won't
send any notification to JAVA side so that the MediaControlService can't change
the correct playing icon.
Therefore, we create new event to inform this situation.
MozReview-Commit-ID: zScaHxvHXM
--HG--
extra : rebase_source : e1434840de36d8621a58fc7406b0f42673a2f3db
The specification doesn't require there to be a 'type' member of
the keyids init data format.
MozReview-Commit-ID: 7mOm7KwyyuC
--HG--
extra : rebase_source : 88b729ae0b0f851763bbd06ec48bae2d6ac1c47e
This means 'waitingforkey' will be fired at a predictable time.
MozReview-Commit-ID: HMt1RbgrbuR
--HG--
extra : rebase_source : cb8c36eacd3e78ae5105cd30da7a51d8241dbd5b
totalVideoFrameCount was previously incorrectly set to the number of demuxed
frames.
According to the current W3C specs [1], it should instead be the total number of
frames that have been presented, plus frames that have been discarded.
Also added a check that discarded<=total in mochitest.
[1] https://wicg.github.io/media-playback-quality/#concepts
MozReview-Commit-ID: Gnv1roM5n0A
--HG--
extra : rebase_source : 1f018612fbaf43867f5c92e59d62d718a3b08535
There hasn't been any traction on this feature, and we keep
paying the maintenance and code size and memory usage penalty
of having this implementation.
We can revive this from VCS history in the future if we decide
to start working on it again. In the mean time, it's better
to remove it.
The spec used to say that getting the .ping property on
HTMLAnchorElement or HTMLAreaElement should return a DOMTokenList of
parsed URLs, but it now says to return a plain string. All other UAs
that implement ping match the new spec, and it's hopefully unlikely that
any sites depend on our old behavior.
Discussion: https://github.com/whatwg/html/issues/1780
MozReview-Commit-ID: LpmH8ANNT9g
The idea is to not make consumers think about whether the principal exists or
not when the caller knows for sure that it does.
The substantive changes are in dom/bindings, nsHTMLDocument::SetDesignMode, and
around the CanUseStorage bits. Everything else is pretty mechanical.
Since I want to use more agent's functions in MediaElement and I don't think these functions need to be exposed on IDL level. (for other languages binding)
Therefore, I want to use AudioChannelAgent directly in MediaElement.
MozReview-Commit-ID: 43FvDeLpZPt
--HG--
extra : rebase_source : 78741d791eb66cfb6223866ce823f217e3438fdb
Regression by bug1262053 because of removing the current playing checking.
It would cause that the media control on Fennec shows too early and some media
elements would also generate the media control even it doens't have available
source.
Therefore, I think we still need to add this checking back.
MozReview-Commit-ID: 1m1ywmLmpSe
--HG--
extra : rebase_source : 30741b0e7bf1bb15349caaf1ecbcdad8cd92dcc3
8eef5d2cc850 in Bug 1300654 incorrectly resolved a merge conflict and backed
out part of the fix for Bug 1280829. Relanding.
MozReview-Commit-ID: 6DIkUrc9R4t
Also replace the check for IsPotentiallyPlaying() with !mPaused because mReadyState >= HAVE_FUTURE_DATA guarantees playback is not ended.
MozReview-Commit-ID: HetaVDgYEW0
--HG--
extra : rebase_source : 94dd2156db419240ad4462208540e9f98f1c8050
HSTS priming changes the order of mixed-content blocking and HSTS
upgrades, and adds a priming request to check if a mixed-content load is
accesible over HTTPS and the server supports upgrading via the
Strict-Transport-Security header.
Every call site that uses AsyncOpen2 passes through the mixed-content
blocker, and has a LoadInfo. If the mixed-content blocker marks the load as
needing HSTS priming, nsHttpChannel will build and send an HSTS priming
request on the same URI with the scheme upgraded to HTTPS. If the server
allows the upgrade, then channel performs an internal redirect to the HTTPS URI,
otherwise use the result of mixed-content blocker to allow or block the
load.
nsISiteSecurityService adds an optional boolean out parameter to
determine if the HSTS state is already cached for negative assertions.
If the host has been probed within the previous 24 hours, no HSTS
priming check will be sent.
MozReview-Commit-ID: ES1JruCtDdX
--HG--
extra : rebase_source : 2ac6c93c49f2862fc0b9e595eb0598cd1ea4bedf
Previously, we'd block loading of non-MSE content when there was a MediaKeys
attached, that is, we'd assume that all content was EME content if a MediaKeys
was attached. But some sites attach a MediaKeys and then load non-MSE non-EME
content, and that (despite being a bit silly) shouldn't fail.
MozReview-Commit-ID: 9LupWaehXim
--HG--
extra : rebase_source : 6db281feb27a61b49dc565d4d4562a3d2366fc89
This API has been deployed to release for some time. There isi
no longer value to being able to quickly disable it.
MozReview-Commit-ID: Jj6CyWzP93g
--HG--
extra : rebase_source : 2dc0547229b53865a4f7cfcf7ca417eb3dec0356
There's no such step defined in the spec. Despite, this code can no longer be called when readyState is HAVE_NOTHING
MozReview-Commit-ID: 2fDoNHt1COp
--HG--
extra : rebase_source : d8b79acee85b00331f55153626038e26cd4a72c7
There's no such step defined in the spec. Despite, this code can no longer be called when readyState is HAVE_NOTHING
MozReview-Commit-ID: 2fDoNHt1COp
--HG--
extra : rebase_source : baa542cdf3144db8b941c20f22548c67bfc06346
Instead of "not visible", "approximately visible", and "visible" (in display port) we now have "approximately not visible", and "approximately visible" which includes "visible".
Instead of "not visible", "approximately visible", and "visible" (in display port) we now have "approximately not visible", and "approximately visible" which includes "visible".
When swapping content from <iframe mozbrowser> to <xul:browser>, we now stop the
frame scripts that implement the content side of the browser API since they are
no longer needed and can cause issues if they remain active.
MozReview-Commit-ID: JrecxA4MI93
--HG--
extra : rebase_source : cc68b975c7d82035410a647ff66eab130055ed04
After using enum class, a switch-case warning in CombineBreakType is caught.
This is one of such kind safty checks that we would like to gain.
Fix it by adding default case for switch-case in CombineBreakType.
MozReview-Commit-ID: BdS3LPN6qzX
--HG--
extra : rebase_source : 17f24a0d482ed6eb51b23e6942d0ac1c87375e0b
Enable nsAttrValue::EnumTable to be initialized with enum. So, we could get rid
of the castings in EnumTable. Fix EnumTable initialization comment.
For those untyped enumerations, declare them with uint8_t, as to other typed
enumerations with type size larger than int16_t, force casting to int16_t.
Use {nullptr,0} instead of {0} to represent the last entry.
MozReview-Commit-ID: 7Dma3Apkmxj
--HG--
extra : rebase_source : b2289866c4c33d80c8e170727bf109d018d92f67
They are non-standard aliases for "DragEvent" and "KeyboardEvent" that
are not supported by any other UA, and we would like to drop support.
So first let's stop using them ourselves, so we can use telemetry to see
if any sites are using them.
MozReview-Commit-ID: ICC33ORa2st
In ancient degisn, we would only register audio channel after the media element has audio track and enoguh data to playback,
that is because the "audio-playback" event would be dispatched with the registration, and then shows the tab audio indicator.
However, now the event dispatching doesn't follow with the registration, it would be triggered when the media element has
really audible data which would be notified from media decoder.
Therefore, the media element without audio track or without enough data can also register audio channel agent, it won't affect
the display of tab audio indicator. The reason we need to do that is for blocking autoplay media in the non-visited tab.
The autoplay can be adding "autoplay" keyword or playing by the script, and we don't want to dispatch dom event for blocked
media. Therefore, we should register audio channel agent to know whether it needs to be blocked immediately even the media
element doesn't have any enough data which can let us to distinguish it have any audio track or not (this information can
be known from metadata).
First, we must check whether the media is blocked which is notified by audio channel agent, and then we can decide whether
need to dispatch the event. If we don't register audio channel agent, that we can't get blocking information.
MozReview-Commit-ID: HLLkOuecql1
--HG--
extra : rebase_source : 99c34f0185276ecd5b70ae09959b47c584d1564e
If the media was blocked, we would postpone the dom event and dispatch them after media is resumed.
MozReview-Commit-ID: LcdJtH16qQn
--HG--
extra : rebase_source : 209d18925a88a9e0dac82f2c0695ec1b60f54f63
The spec recently changed to match browsers better. There's currently
not much interop in exact details of how this work. This brings us in
line with the spec except for the limit of 1000 on the span attribute.
The added textarea failures are spurious, because I'm not updating our
local tests in this commit. The new tests are submitted upstream at
<https://github.com/w3c/web-platform-tests/pull/3518>.
MozReview-Commit-ID: 1L8aUtF47Qi
This adds support for HTMLMediaElement.mozCaptureStream() and
mozCaptureStreamUntilEnded() for a HTMLMediaElement playing a MediaStream.
This is up to spec, while capturing a HTMLMediaElement playing a file is not.
This incompatibility means we cannot mix sources for the returned MediaStream.
As such, a MediaStream returned while the HTMLMediaElement was playing a file
will only have content while the element is playing files. If the src changes
to a MediaStream, the stream will be empty.
It works the same way if a MediaStream was captured while the HTMLMediaElement
was playing another MediaStream.
This is due to TrackID management - MediaDecoder doesn't care, and creates new
tracks when you seek, so users are unable to keep track, while for MediaStream
we control everything from main thread and keep track of the TrackIDs used
previously.
This also adds a separate path from MediaElementAudioSourceNode so that we don't
forward video tracks when the returned MediaStream is only used internally for
WebAudio. We should in that case not require a DOMMediaStream but just forwarding
tracks to a TrackUnionStream should be enough, and will save us some cpu cycles.
This is however fine for now as it's simpler.
MozReview-Commit-ID: Bg8hESDISDU
--HG--
extra : rebase_source : 83885a73ec8cfc5fbe3c30a9330a52cd6b6dff12
extra : source : f1aec79078869c0a6435a1c06957c649d7a40dd9
Sometimes a track is added to a stream synchronously (before the stream is
exposed to script), and sometimes asynchronously (see the mediacapture-main spec
on the "addtrack" event).
In the latter case we might still need to create the MediaStreamTrack object
synchronously for tracking purposes. CaptureStream of Media element playing a
MediaStream wants this.
MozReview-Commit-ID: 7me8xzN7rwj
--HG--
extra : rebase_source : 4f129b127b855e47aad2ae9ab3981ffde057412d
This prepares HTMLMediaElement for having a separate MediaStreamTrackSource for
MediaStreams, StreamCaptureTrackSource.
MozReview-Commit-ID: FVrYxFgvXgA
--HG--
extra : rebase_source : 5c162a0e861fa693fea0ba6b94b8e45446c0c13c
extra : source : a9151ac77a81573b8dbd9fee9c8aa09ba8dc7812
On Linux x64 PGO try, HTMLMediaElement was reliably invoking
decoder->NotifyOwnerActivityChanged() after SetVisible(false) was
called. This caused the pending suspend to be cancelled and the test
waits for an event that never arrives.
Fixed by adding 'forced hidden' to MediaDecoder that overrides the
element visibility that comes from HTMLMediaElement.
MozReview-Commit-ID: 5aRhxxZ5cZd
--HG--
extra : rebase_source : 5a4e1c44ddd2265eab545f8fe19c4ae47cebf7bf
Bubble information from SamplesWaitingForKey to an HTMLMediaElement so that we
can emit a waitingForKey event. If we are unable to decode more samples due to
needing a key the event will be signalled. See
http://w3c.github.io/encrypted-media/#dom-evt-waitingforkey for more information
on this event.
The code in place before this patch handles updating readyState when we are
waiting for a key, this patch adds the event which should be emitted in such a
case. The spec defines certain preconditions should be the case before running
the algo to emit this event. For example, the element should potentially be
playing, and it should have at least HAVE_FUTURE_DATA ready state. This is not
strictly true for when the new code is run, due how existing code handles ready
state. We are honoring the spirit of the spec, though the letter of the spec is
lightly gone against in the handling of the preconditions.
MozReview-Commit-ID: LKlDd4wkRSE
--HG--
extra : rebase_source : 2c61fc41636e430afa23240ad5d26c886124d87f
Previously we supported insertParagraph as a synonym for formatBlock
"p", which is both useless and incompatible with all other browsers.
Edge's behavior doesn't look useful and looks redundant with insertHTML
(although it matches the name nicely, probably because they invented
the command). Blink/WebKit treat it the same as hitting Enter, which is
useful for cross-browser testing until we get synthesizeKey() in wpt.
At the same time, I added insertLineBreak, which Blink/WebKit support
with the same functionality as pressing Shift-Enter.
The new event.html failures are spurious -- we used to pass by mistake
because we didn't support insertlinebreak at all. insertlinebreak.html
has only new passes, no new failures, although it's not clear on the
diff.
MozReview-Commit-ID: 16oPcxXwGcj
This change avoids lots of false positives for Coverity's CHECKED_RETURN
warning, caused by NS_WARN_IF's current use in both statement-style and
expression-style.
In the case where the code within the NS_WARN_IF has side-effects, I made the
following change.
> NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
> -->
> Unused << NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
In the case where the code within the NS_WARN_IF lacks side-effects, I made the
following change.
> NS_WARN_IF(!condWithoutSideEffects);
> -->
> NS_WARNING_ASSERTION(condWithoutSideEffects, "msg");
This has two improvements.
- The condition is not evaluated in non-debug builds.
- The sense of the condition is inverted to the familiar "this condition should
be true" sense used in assertions.
A common variation on the side-effect-free case is the following.
> nsresult rv = Fn();
> NS_WARN_IF_(NS_FAILED(rv));
> -->
> DebugOnly<nsresult rv> = Fn();
> NS_WARNING_ASSERTION(NS_SUCCEEDED(rv), "Fn failed");
--HG--
extra : rebase_source : 58788245021096efa8372a9dc1d597a611d45611
We will now record '0' in VIDEO_INTER_KEYFRAME_MAX_MS when only one keyframe is
found when playing a video (played for at least enough time to be eligible for
video-decode-suspend feature.)
MozReview-Commit-ID: ALDmSYxs2f1
--HG--
extra : rebase_source : 70b19e9c5c976f764a744dc4bf7a0760e80dd834
Phil Ringnalda
Alastor Wu
Milan Sreckovic
Boris Zbarsky
Sebastian Hengst
Wes Kocher
Jean-Yves Avenard
Andreas Pehrson
JW Wang
Andrea Marchesini
Xidorn Quan
Jessica Jong
Carsten "Tomcat" Book
Bryce Van Dyk
Adam Velebil
Aryeh Gregor
Ryan VanderMeulen
Michael Layzell
Chris Pearce
Michelangelo De Simone
Valentin Gosu
Gerald Squelart
Iris Hsiao
Edgar Chen
Jon Coppeard
Ehsan Akhgari
bechen
Thomas Wisniewski
Olli Pettay
Josh Matthews
Tom Puttemans
Michael Kaply
James Andreou
Kate McKinley
James Cheng
Paul Bignier
Thomas Nguyen
Jan Beich
Domenic Denicola
Manish Goregaokar
Shing Lyu
Ralph Giles
Nicolas Silva
Stone Shih
kaku@mozilla.com
Kaku Kuo
Timothy Nikkel
Kevin Chan
J. Ryan Stinnett
Jeremy Chen
Cameron McCormack
Andi-Bogdan Postelnicu
Lee Salzman
Dan Glastonbury
Decky Coss
Nicholas Nethercote
John Dai
Bobby Holley