So we won't pass an unused |nsIStreamListener**| to MediaSourceDecoder::Load().
MozReview-Commit-ID: 2TCby8m8K5H
--HG--
extra : rebase_source : 349179aa4303c0abd8b86a695789770e158e5c28
extra : intermediate-source : d6f550bd6709a0ee7db6033286af42565a20cdb1
extra : source : ed524d855a1a78665c499152a9360ba961655641
Now we can init some members in the constructor and remove the setters
that are called only once.
MozReview-Commit-ID: 2hkrIA6pFlh
--HG--
extra : rebase_source : 33c008ef1508597e64ef7f92b028867dbd4ffba6
extra : source : fa213ee733ea881f4f76dac06c9b4709aeba4b91
We will add more fields to MediaDecoderInit and be able to remove some setters.
MozReview-Commit-ID: BVx935IHQHf
--HG--
extra : rebase_source : 6d167265e478ce39881ceada1303e9ca18189bbf
extra : source : 0c26f909568f673591ad6720458dfc912c01daad
This is necessary to facilitate the transition to cloning attributes instead of reparsing them.
MozReview-Commit-ID: Gyd1tD6ldly
--HG--
extra : rebase_source : 777cfed750c95c448f953a6ec98026481997e227
MSE specs require that the readyState be modified during either the Initialization Segment Received or the Coded Frame Processing algorithms.
At this stage, we only handle the Initialization Segment part (readyState moving from HAVE_NOTHING to HAVE_METADATA)
MozReview-Commit-ID: KBnnWuHJ6Om
--HG--
extra : rebase_source : a4450139762d5d033438fbee2ce560fe02ed6ffc
The spec says that we don't need to change the ready state when getting the error.
If the ready state is "HAVE_METADATA", it means we could get the video's duration
at that time.
However, if we shutdown decoder too early, we won't get the correct duration.
In addition, since we remove old decoder prior to create new one in the function
HTMLMediaElement::SetDecoder(), we can remove the decoder checking assertion
in HTMLMediaElement::InitializeDecoderForChannel().
MozReview-Commit-ID: CHRJHng8Xm0
--HG--
extra : rebase_source : 32b2114f5b4bce2d777826295959a6ce0701984d
In order to facilitate the movement of code with side-effects called by Element::SetAttr to Element::BeforeSetAttr and Element::AfterSetAttr, Element::AfterSetAttr should have access to the old value of the attribute. This includes information about whether there was previously a value set or not.
Accomplishing this involved passing an additional argument through functions that find and change the old attribute value in order to ensure that we can differentiate between an empty old value and an absent old value (attribute was not set).
Note that while I tried to ensure that accurate values (and their absence) are reported to Element::AfterSetAttr, I largely ignored SVG. While the old value reported for SVG values should be however accurate the value already being reported to SetAttrAndNotify was, SVG elements do not currently report unset values properly because they will never pass a null pointer to SetAttrAndNotify.
MozReview-Commit-ID: K1mha8CNFZP
--HG--
extra : rebase_source : 42776eb01451d371e4aebcc17fe3dd112c8d268b
Defer determining whether we have usable decoders to an off-main thread in
order to avoid janking the main thread.
MozReview-Commit-ID: Ape5zEBBMrz
--HG--
extra : rebase_source : 1b77046ebb7bb2d4ff1ba53afce904d3de45c335
Since we don't want to show media control for media without audio track (eg. GIFV),
it's no need to register audio agent for them.
MozReview-Commit-ID: 22YrMkpNrcP
--HG--
extra : rebase_source : 78a6c41b6018f91ed9370fb2f15c650fe76ba3a1
Should also update audio playing changed after resumed from page.
MozReview-Commit-ID: 66vuJJFeWN3
--HG--
extra : rebase_source : 06802b2e49f5e712a1d9fd34d4ae017995faaa75
The part is mainly to set urgent-start for loading media when it's initiated by
user interaction. For the HTMLMedia element, it has its algorithm to pre-load
the media and users will get feedback once they play the media. Thus, I only
set urgent-start when the media element has autoplay attribute since the sooner
enough resource is loaded the sooner the media will be played.
MozReview-Commit-ID: 7nu3PUt8iYo
--HG--
extra : rebase_source : f1abfecdccb74f4ec79a057534c2e9a1bfd5ae41
Otherwise we will fail the assertion (!mDecoder, "Shouldn't have a decoder")
in HTMLMediaElement::InitializeDecoderForChannel().
MozReview-Commit-ID: 1zShp0th3Uv
--HG--
extra : rebase_source : 9b61fd8f6817e33c7d041e4b49bc34ccbc357a15
The crash happens when:
1. there are multiple <source> children.
2. decode error happens on the 1st child.
MozReview-Commit-ID: 60UXaQ475Nh
--HG--
extra : rebase_source : b7e61ae909cfa10fb2db3c41b278449de41b9450
Currently, attribute and child arrays (implemented in dom/base/nsAttrAndChildArray.h) start out empty. When cloning, the array ends up being resized multiple times in order to add the attributes and children that are being cloned from the original node. This would be quicker if the array was initialized to the correct size in the first place so that resizes are not necessary.
However, preallocating space for children is only necessary when performing a deep clone. Therefore, an additional parameter is being added to the Clone, CopyInnerTo, and CloneDocHelper methods to indicate whether preallocation of children should happen. Attributes are copied either way, so that part of the array is preallocated in both cases.
MozReview-Commit-ID: 3iVezeAKXnI
--HG--
extra : rebase_source : 9c3deec6d7aafd6411044d623d4863637b45fd58
There was a cycle amoung a window object -> a HTMLMediaElement -> a MediaDecoder -> a Promise (-> back to the window object).
And we have no way to break the cycle since the MediaDecoder does not participate into the collection.
By moving the Promise form MediaDecoder to HTMLMediaElement, we will be able to break the cycle since the HTMLMediaElement is in the collection.
We'll implement the cycle collection in the next patch.
MozReview-Commit-ID: CyVXBl6IMI3
--HG--
extra : rebase_source : 195a322ce3e6fe933e72be4aec5d2ebfa1f54865
On Fennec, we use external video player to play unsupported type media.
In this bug, we can't execute play() successfully because the spec said that
we should abort the play if the value of media element's error is
MEDIA_ERR_SRC_NOT_SUPPORTED [1].
Therefore, we do a hack for unsupported type media, we don't set its error, but
we would still remember the src is unsupported type. When media element starts
playing, we would use an external video player to play that src.
[1] https://goo.gl/GlLbeA
MozReview-Commit-ID: 42HxQtXdWDe
--HG--
extra : rebase_source : 83425528eacee8af1829eaead2fef39b0be51ae5
Since the audible state would depend on pause and suspend state, we should do
the check after finishing play() or pause().
MozReview-Commit-ID: 1yhxuQDw067
--HG--
extra : rebase_source : 888bac3da52f42b75eeb1c3db1337e223d792a11
If the media element is paused, it should be non-audible.
MozReview-Commit-ID: 2HjV9gNNcnV
--HG--
extra : rebase_source : 39b0812788d020d3f9c1a96afa1397b32057de8c
Since the window would know when need to resume the media, we don't need the
add/removeMediaContent() anymore.
MozReview-Commit-ID: F9MSiqqnOiV
--HG--
extra : rebase_source : fa86b3977e13d1f2a6b6233b6d608ccc331b5bf7
Since the window would know when need to resume the media, we don't need the
add/removeMediaContent() anymore.
MozReview-Commit-ID: F9MSiqqnOiV
--HG--
extra : rebase_source : 28a8312373054b8e29b93267677de99dd862a074