MediaContentType can only be created through MakeMediaContentType(), which
returns a Maybe<MediaContentType>.
If the return value is Nothing, parsing failed.
Otherwise the contained MediaContentType object is guaranteed to be valid;
E.g., GetMIMEType() will always return a non-empty string.
Note that this interface will change a lot in the following bugs&patches, so
please don't worry about the 'Get' in the never-failing GetMIMEType(), it will
be gone soon!
MozReview-Commit-ID: IjGKkQ6RVd4
--HG--
extra : rebase_source : 5254af80dec0beb05da49f68c12fecc28edd725e
Because we add tracks to the output streams async, it's possible to switch the
mSrcStream of a media element and *then* get a notification of an added track,
when this track originated from the old mSrcStream.
If the new mSrcStream is an output stream of the media element, this would
again add a new track async, which on the next event loop spin would show up
on mSrcStream, and the loop continues.
MozReview-Commit-ID: HmKgXLYmubh
--HG--
extra : rebase_source : 242f864e79b0b2335719a07fe9ee4b8b940d85dc
With the attached test case I was failing an assert in a debug build because
NotifyMediaTrackEnabled exited early due to `mReadyState == HAVE_NOTHING` but
NotifyMediaTrackDisabled didn't. The latter would fail an assert.
MozReview-Commit-ID: 7Frpj62s0Bc
--HG--
extra : rebase_source : a1dea4f2db564fe28e6eb7f7fcd9c382a46409ac
With this patch, the disabled state is still kept in the nsPresState,
but we will only honor that if the state saved asks as to re-enable the
control.
The behavior is changed so that controls disabled by JavaScript will be
kept enabled as the JavaScript world gets reloaded.
MozReview-Commit-ID: 6PchHfx6KYX
--HG--
extra : rebase_source : 19399db854cc7cb80f45940bfc378c3e09c2979c
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