This is a drive-by fix in that it is not directly related to what the bug is
solving. However, making HTMLMediaElement register as a sink is important,
and pairing it with the WeakPtr<Sink> patch reduces risk greatly.
MozReview-Commit-ID: 7pMDw3MG0ZB
--HG--
extra : rebase_source : e2f2b3a12b9921373518d94a083adda23bfe853b
This patch implements HTMLMediaElement::GetEventTargetParent and set
aVisitor.mCanHandle to false to mouse/touch/pointer events, when
the media control is present. This tells the event dispatcher that
these events are supposed to be handled exclusively by the
videocontrol binding within the media element, and should not
dispatch nor consumed by the content.
MozReview-Commit-ID: BXWZX9SYsuC
--HG--
extra : rebase_source : 5d6633a2e1a456d2d619b6f68498065d94c68c40
This patch implements HTMLMediaElement::GetEventTargetParent and set
aVisitor.mCanHandle to false to mouse/touch/pointer events, when
the media control is present. This tells the event dispatcher that
these events are supposed to be handled exclusively by the
videocontrol binding within the media element, and should not
dispatch nor consumed by the content.
MozReview-Commit-ID: BXWZX9SYsuC
--HG--
extra : rebase_source : e9922ac6064c953ee233d6829e84bc7828518b43
The MediaKeys status inside a HTMLME cannot be reflected correctly if the mSetCDMRequest is disconnected in HTMLME::ShutdownDecoder.
This may happen when a page calls load() or sets new src right after setting MediaKeys to null.
MozReview-Commit-ID: 3BZOmw7BNFO
--HG--
extra : rebase_source : f06ae54944133e8e48471e71f0bb8fe46290cca8
1. move all checks to CanActivateAutoplay()
2. don't cache the pref's value in advance, it might cause wrong result
if user changes pref after media was binded to tree.
MozReview-Commit-ID: 3BeOeaq9wGa
--HG--
extra : rebase_source : 74085dce2852d0a608f6455bd0b9337b8223fa20
The return value is unchecked in MediaDecoder, and we only ever returned
NS_OK anyway. And we if the dispatch fails, we can't really do anything;
dispatching an "error" event probably won't work.
MozReview-Commit-ID: 67K6Mjft6tY
--HG--
extra : rebase_source : ad644e8b97fc11488983bc05e18c9941b3c5b062
We queried 'loadingprincipal' attribute on the common call path, however
this should be queried if it's loaded by System Principal.
Also rename loadingprincipal to triggeringprincipal
MDSM doesn't reset the decoding pipeline of MFR when doing NextFrameSeek and
therefore fails the assertion by requesting video data while MFR is still seeking.
We put the fix in the media element because it doesn't make sense to do
NextFrameSeek while another seek is already in action.
MozReview-Commit-ID: D6FSiNWHrLU
--HG--
extra : rebase_source : 7793fa32fb5fe3406f235aa43908a8a96202ee6c
The old code doesn't print readyState changes when networkState is EMPTY.
MozReview-Commit-ID: 8rWUbpsmNuu
--HG--
extra : rebase_source : 509ebf1ae94e2618e63c764ef8fdf0869cb60582
Now DecoderTraits doesn't need to depend on ChannelMediaDecoder.
MozReview-Commit-ID: D4AUiV2eGWy
--HG--
extra : rebase_source : 38e6c4cdd0f7e32473c6945550bca6fd0cc72bf2
See comment 3 for the root cause.
MozReview-Commit-ID: CX5npKv2eWG
--HG--
extra : rebase_source : 085192f55b082f878d2f9915c24e89a56a981799
extra : source : 07f12b6df9d35eb3d215835a174504c70120b588
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
--HG--
extra : rebase_source : 25e438c243700a9368c393e40e3a6002d968d6c8
(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
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
Also assert readyState is HAVE_NOTHING before creating a new decoder.
MozReview-Commit-ID: B0QACf96AA3
--HG--
extra : amend_source : ef4b41db04ee10f7eaae8f388d984ed0fd0863b5
