Looks like these three APIs slipped through when shipping v1, but no other
vendor supports them, so no reason to be here.
I don't think there's any harm in letting the implementations keep living in
DocumentOrShadowRoot, but let me know if you think otherwise and I'll move them
to Document.
Differential Revision: https://phabricator.services.mozilla.com/D23577
--HG--
extra : moz-landing-system : lando
It would be helpful if we can also print the information in `TextTrack` and `TextTrackCue`.
Differential Revision: https://phabricator.services.mozilla.com/D23449
--HG--
extra : moz-landing-system : lando
Automatically print `TextTrackManager`'s address for the log marco, also update some exist logs.
Differential Revision: https://phabricator.services.mozilla.com/D23448
--HG--
extra : moz-landing-system : lando
Use more general name `WebVTT` for this log module, which will include other debug logs in other files later.
Differential Revision: https://phabricator.services.mozilla.com/D23447
--HG--
extra : moz-landing-system : lando
In this comparison, we only process `hidden` or `showing` track which should not return null TextTrackCueList.
Differential Revision: https://phabricator.services.mozilla.com/D23087
--HG--
extra : moz-landing-system : lando
In order to make the implementation more fitting with the spec, move the implementation of `pending-text-track-change-notification-flag` from text track list to media element.
In addition, it also help us not to expose the internal flag `show-poster` (which will be implemented in patch3) of media element when doing the related algorithm.
Differential Revision: https://phabricator.services.mozilla.com/D21810
--HG--
extra : moz-landing-system : lando
Create a new parser (PrototypeDocumentParser) and content sink
(PrototypeDocumentContentSink) that can be used by both XUL and XHTML.
The new parser moves the code from XULDocument that handles creating and
loading a nsXULPrototypeDocument from either the cache or the source
file. Once the parser has finished loading the prototype it notifies the
content sink. The parser is largely a stub and would be better suited
for use as a nsBaseParser, but nsHTMLDocument unfortunately needs an
nsIParser.
The new content sink has the XULDocument code responsible for the
prototype traversal that creates the DOM (XULDocument::ResumeWalk and
friends) and fires off various events.
To unify XUL and XHTML, the XHTML readystate event sequence is used in
XUL. However, the layout path of XHTML loaded from the prototype cache
more closely follows XUL, where frame initializers and layout don't
start until the entire DOM is built.
Differential Revision: https://phabricator.services.mozilla.com/D21236
--HG--
rename : dom/xul/XULDocument.cpp => dom/prototype/PrototypeDocumentContentSink.cpp
rename : parser/moz.build => dom/prototype/moz.build
rename : parser/moz.build => parser/prototype/moz.build
extra : moz-landing-system : lando
We should update cue display everytime when the cues list changed.
In addition, we shouldn't check whether cue is active when we update display, because it's always inactive when the cue has been removed from `TextTrack::RemoveCue()`.
Differential Revision: https://phabricator.services.mozilla.com/D21143
--HG--
extra : moz-landing-system : lando
As the `active cues list` would be automatically contruct when there are any active cues being added or inactive cues being removed, we have no need to use dirty to reset the `active cues list`.
Differential Revision: https://phabricator.services.mozilla.com/D22150
--HG--
extra : moz-landing-system : lando
According to the spec [1], the `current cue` is not equal with the `active cue`, because it might contain non active cues, which might be set to active later during the `TimeMarchesOn`.
The `current cue` should be a list of cues, initialized to contain all the cues of all the hidden or showing text tracks of the media element (not the disabled ones) whose start times are less than or equal to the current playback position and whose end times are greater than the current playback position.
[1] https://html.spec.whatwg.org/multipage/media.html#time-marches-on
Differential Revision: https://phabricator.services.mozilla.com/D22148
--HG--
extra : moz-landing-system : lando
In order to make the implementation more fitting with the spec, move the implementation of `pending-text-track-change-notification-flag` from text track list to media element.
In addition, it also help us not to expose the internal flag `show-poster` (which will be implemented in patch3) of media element when doing the related algorithm.
Differential Revision: https://phabricator.services.mozilla.com/D21810
--HG--
extra : moz-landing-system : lando
Based on the current implementation of nsContentUtils::IsPlainTextType(), we
could just call that function again if we need to know whether we're
dealing with plain text content or not later on, but doing it this way ensures
we're always consistent with the current code in StartDocumentLoad(), which
includes some additional sanity checks.
Differential Revision: https://phabricator.services.mozilla.com/D20952
--HG--
extra : rebase_source : 5d4606c2c6bc11b2a7f91c221c17c8405fff44b8
extra : amend_source : 6856439650748cdb41e635044c17d6fbf387110b
extra : intermediate-source : 6a5a3077c438a5299fb0752fefb01a081e1f7d96
extra : source : cfb68d7c93bac96fdf979be90116c2de0df76d71
Hiding document.createEvent("TouchEvent"), document.createTouch, document.createTouchList and ontouch* event
handlers on desktop to follow what Chrome has done.
This patch explicitly does not remove createTouch or createTouchList everywhere, although those seem to have been
removing already on some other browsers.
Devtools use TOUCHEVENTS_OVERRIDE_ENABLED for touch event testing, and this patch keeps the old behavior per discussion
with devtools devs.
Differential Revision: https://phabricator.services.mozilla.com/D22081
--HG--
extra : rebase_source : 562588a289632ba2f11db7f3ac8782c26c3b05f8
MediaKeys objects are typically created and associated with an HTMLMediaElement,
however it is possible to create a MediaKeys object and not associate it with an
HTMLMediaElement.
This resulted in an issue where these MediaKeys would keep alive other
components that would assert during bowrser shutdown (see bug 1522547). We
anticipated that MediaKeys associated with an HTMLMediaElement would need to be
shutdown if their owning document became inactive, but were not handling the
case where the keys never became associated with an element.
This patch has the MediaKeys listen directly to their owning document for
activity change. The MediaKeys will shutdown if their document becomes inactive.
This avoids MediaKeys not associated with HTMLMediaElements keeping other
objects alive during browser shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D21983
--HG--
extra : moz-landing-system : lando
Based on the current implementation of nsContentUtils::IsPlainTextType(), we
could just call that function again if we need to know whether we're
dealing with plain text content or not later on, but doing it this way ensures
we're always consistent with the current code in StartDocumentLoad(), which
includes some additional sanity checks.
Differential Revision: https://phabricator.services.mozilla.com/D20952
--HG--
extra : moz-landing-system : lando
In order to display blocking icon when the document comes back from the bfcache, we have to notify front end what's the current blocking status.
As the front end side would clear blocking autoplay information when nagivation occurs, and the media might not invoke the play again when they comes back from the bfcache.
Therefore, we should notify front end side that the site is still being blocked, and we should show blocking icon for it.
Differential Revision: https://phabricator.services.mozilla.com/D21582
--HG--
extra : moz-landing-system : lando
Most remaining code in `PresShell::EventHandler::HandleEvent()` is what computes
event target of the event which should be handled on focused content. This
patch moves the part to the new method.
Additionally, moves `nsIPresShell::gKeyDownTarget` to
`EventHandler::sLastKeyDownEventTargetElement` and make it use `StaticRefPtr`.
Finally, for using `Element*` instead of `nsIContent*`, changes the result type
of `Document::GetUnfocusedKeyEventTarget()` to `Element*`.
Differential Revision: https://phabricator.services.mozilla.com/D21195
--HG--
extra : moz-landing-system : lando
