According to current WhatWG HTML spec, the checking of media attribute in SourceElement is removed. Fix the Gecko code to reflect current spec.
MozReview-Commit-ID: 43d9zL9Fvih
--HG--
extra : rebase_source : beb87387cb1d55eb42713fbb0d344c0c64a0b6da
W3C HTML5 spec isn't very actively maintained now. WhatWG HTML spec:
When a media element is removed from a Document, the user agent must run the following steps:
Below is the related statement in WhatWG HTML spec:
Await a stable state, allowing the task that removed the media element from the Document to continue. The synchronous section consists of all the remaining steps of this algorithm. (Steps in the synchronous section are marked with ⌛.)
⌛ If the media element is in a document, abort these steps.
⌛ Run the internal pause steps for the media element.
MozReview-Commit-ID: H4EgPqj2YxD
--HG--
extra : rebase_source : 2c15adaaadd955662797dcf1c5158927f16bab97
Buffered range is now calculated asynchronously. It may not be up to date by the time the MDSM has entered ended mode.
There's no point estimating readyState in ended mode anyway: we know what it is...
MozReview-Commit-ID: ErGsAwBzeXI
--HG--
extra : rebase_source : db3bde99b21f5b4377ce88509979f1499b1cd677
Doing QI from nsIEditor to nsIEditorIMESupport doesn't make sense because editor should always support all methods and attributes of nsIEditorIMESupport (it does NOT mean that all nsIEditor implementation need to support IME).
This patch moves all of them to nsIEditor for avoiding redundant QIs.
MozReview-Commit-ID: DzIKuGHG4iy
--HG--
extra : rebase_source : cc5e9a6ae4572ebe461d9770ffa5c23d33dc8526
Buffered range is now calculated asynchronously. It may not be up to date by the time the MDSM has entered ended mode.
There's no point estimating readyState in ended mode anyway: we know what it is...
MozReview-Commit-ID: ErGsAwBzeXI
--HG--
extra : rebase_source : bd8cecca96e93114e970e09faf09a80f56bf4c98
Dispatch |QueueLoadFromSourceTask| to main thread to make sure the task will be executed later than loadstart event. And when the src get errors, we need to end the synchronous section.
MozReview-Commit-ID: EQ0jVIMnqoZ
--HG--
extra : rebase_source : 876c62669f56581e903830beddbf0ce4435366e2
4.8.12.5
https://html.spec.whatwg.org/multipage/embedded-content.html#media-element-load-algorithim
The living WHATWG spec has been changed since I implemented this patch.
Will update to the latest spec later.
MozReview-Commit-ID: 7U1AC2Ua83Z
--HG--
extra : rebase_source : d4b7c5103b29271cfdde5d180d7e7c8a65d89b2f
extra : intermediate-source : 616bc473295c8673e3cfae726b8a19c64b2906f1
extra : source : 69d8b411ee5f85139f3f40ce4bc7a4d7ad018b8d
In this patch, the following utilities are implemented:
(1) A list to keep pending promises of a HTMLMediaElement.
(2) A method to take pending promises out from the HTMLMediaElement.
(3) A global function to resolve the passed promises.
(4) A global function to reject the passed promises with an error code.
(5) A method to asynchronously resolve all pending promises of a HTMLMediaElement.
(6) A method to asynchronously reject all pending promises of a HTMLMediaElement.
(7) A method to dispatch a 'playing' event and resolve all the pending play promises.
All the above functionalities are defined at WHATWG 4.8.12.8:
https://html.spec.whatwg.org/multipage/embedded-content.html#list-of-pending-play-promises
This patch also implements two MediaEvent classes, nsResolveOrRejectPendingPlayPromisesRunner and nsNotifyAboutPlayingRunner, which help (5), (6) and (7).
This patch also implements a list of already-dispatched nsResolveOrRejectPendingPlayPromisesRunner; we keep tracing these tasks because the load algorithm resolves/rejects all already-dispatched pending play promises (in patch 2).
MozReview-Commit-ID: EUirNqDfttk
--HG--
extra : rebase_source : e48196e77341926900747b3f9477c5ee9ed28f62
extra : intermediate-source : 9b349c0e9eedad8822a1b8e8ef375ac6cb0b635a
extra : source : 75ee3b084edb68709503c98ad7b72850af7bb9c8
http://searchfox.org/mozilla-central/rev/dc8cf05768b83a6ef0b4039edd6efddd56ee4109/dom/media/MediaDecoderStateMachine.cpp#1065
Changing nextFrameStatus to UNAVAILABLE might change readyState to HAVE_CURRENT_DATA and cause 'waiting' to fire.
It doesn't make sense to fire 'waiting' at the end of playback.
http://searchfox.org/mozilla-central/rev/dc8cf05768b83a6ef0b4039edd6efddd56ee4109/dom/html/HTMLMediaElement.cpp#5423
Note the check for Ended() doesn't work as expected to prevent 'waiting' from firing at the end of playback
because of the way how TailDispatcher schedules stateChange tasks.
This patch keeps readyState in HAVE_ENOUGH_DATA when playback is near the end for wanting no more data.
readyState will change to HAVE_CURRENT_DATA when the playing state of MediaDecoder is changed to PLAY_STATE_ENDED.
MozReview-Commit-ID: 6EspaD2hhx
--HG--
extra : rebase_source : 345aad2757d684e24863ae2daf506b035955efe7
extra : source : 56736efbab04a5c2d66faf2514bac93acf4c79f7
The crash reason seems the mOwner has been released, so we shouldn't call any method which would call mOwner.
The AudioChannelAgentCallback could only be called from two parts, one is from mOwner, another is from AudioChannelService (via AudioChannelAgent).
We don't want this class be called after mOwner was released, we should disconnect it from AudioChannelService.
Calling NotifyStoppedPlaying() can unregister agent from service, so service won't call agent anymore.
Therefore, no one would call AudioChannelAgentCallback after CC happened.
MozReview-Commit-ID: 7HY4KpciacB
--HG--
extra : rebase_source : 228c4988cd5aaae7b8b5c10463eb8445a8771d62
