In order to tailor certain security checks to the caller that is attempting to
load a particular piece of content, we need to be able to attach an
appropriate triggering principal to the corresponding requests. Since most
HTML content is loaded based on attribute values, that means capturing the
subject principal of the caller who sets those attributes, which means making
it available to AfterSetAttr hooks.
MozReview-Commit-ID: BMDL2Uepg0X
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
We register the nsIWebProgressListener at the root docshell(GetSameTypeRootTreeItem) to handle video element embedded in iframe.
MozReview-Commit-ID: D4CavLDAnKD
Fix after an observed nullptr deref on try where mOutputStreams contained an
object whose mStream member had been nulled out.
MozReview-Commit-ID: 4kL1choTeW3
MediaStreamGraph only implements the blocking notifications for SourceMediaStreams,
but the MediaStream that gets attached as srcObject on a media element is always
a TrackUnionStream. Hence, this code is unused and can be removed.
MozReview-Commit-ID: 6DKtCGNsZec
The extension policy services uses atoms internally for permission names, so
using them directly rather than strings is considerably cheaper.
MozReview-Commit-ID: Io8EuOXHKVy
1. since setVolume would trigger updateWakelock(), we should set |mOuter| before that.
2. move outer as required parameter in its constructor.
3. should init all member varaibles which would be referenced by wakeLockWrapper before its initialization.
MozReview-Commit-ID: H9A3aCKp6eT
For knowing the wake lock usage more clearly, we should use more specific topic name.
In OSX, you can use "$ pmset -g assertions" to check all the wakelock.
In Windows, using "$ powser -energy" to generate the energy report.
MozReview-Commit-ID: rAXnkxTvLc
If TimeUnits.h includes mozilla/dom/TimeRanges.h, then the build ends up
pulling in the Gecko DOM bindings, which pulls in a whole lot of JavaScript and
DOM bindings code. That makes it trickier to import GeckoMedia into Servo, and
makes Gecko's build slower, so move the code to convert TimeIntervals into
dom::TimeRanges.
Also remove an extraneous "virtual" and add "const" to some functions in TimeRanges.
MozReview-Commit-ID: BLeehaf9gCE
If AddMediaElementToURITable() is called after the decoder Load failed, mDecoder
will be reset and it is sufficient to assert mDecoder only.
MozReview-Commit-ID: 58WT8zFeiFj
This fixes the bug where mWaitingForKey is reset only when mPaused is false.
We should reset mWaitingForKey to NOT_WAITING_FOR_KEY when the key is
available and decoding can continue.
http://w3c.github.io/encrypted-media/#resume-playback
MozReview-Commit-ID: LjIhe9cTsdg
Instead, MediaDecoder::NextFrameStatus() checks IsEnded() and returns
NEXT_FRAME_UNAVAILABLE to ensure we have HAVE_CURRENT_DATA when playback
is ended on the main thread.
This will fix the timing issue (comment 0) which causes 'waiting' to fire.
MozReview-Commit-ID: 7O21x2q0lb8
This fixes the bug where mWaitingForKey is reset only when mPaused is false.
We should reset mWaitingForKey to NOT_WAITING_FOR_KEY when the key is
available and decoding can continue.
http://w3c.github.io/encrypted-media/#resume-playback
MozReview-Commit-ID: LjIhe9cTsdg
Instead, MediaDecoder::NextFrameStatus() checks IsEnded() and returns
NEXT_FRAME_UNAVAILABLE to ensure we have HAVE_CURRENT_DATA when playback
is ended on the main thread.
This will fix the timing issue (comment 0) which causes 'waiting' to fire.
MozReview-Commit-ID: 7O21x2q0lb8
In bug 1312886, we made sure that readyState would never become HAVE_ENOUGH_DATA if we were waiting for a key.
However, this is in effect useless as the next call to ChangeReadyState would have reset mWaitingForKey.
In practice, it only meant that we delayed the change from HAVE_FUTURE_DATA to HAVE_ENOUGH_DATA until the next call to UpdateReadyState.
MozReview-Commit-ID: 2wnMeN8xxCS
