RESOLVED FIXED 103420
HTMLMediaElement's .textTracks property does not reflect <track> element
https://bugs.webkit.org/show_bug.cgi?id=103420
Summary HTMLMediaElement's .textTracks property does not reflect <track> element
Antoine Quint
Reported 2012-11-27 08:34:37 PST
We fail the Opera-submitted test at http://w3c-test.org/html/tests/submission/Opera/media/interfaces/TextTrackList/getter.html. The first test fails because we don't return the <track> element added to the <video> element as one of the text tracks. Note that when we do, we should respect the first rule of the spec for ordering of text tracks which says that the first items of the list are <track> elements (see http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#list-of-text-tracks).
Attachments
Patch (9.14 KB, patch)
2012-11-27 23:27 PST, Hajime Morrita
no flags
Patch (9.61 KB, patch)
2012-11-29 00:37 PST, Hajime Morrita
no flags
Radar WebKit Bug Importer
Comment 1 2012-11-27 08:35:08 PST
Eric Carlson
Comment 2 2012-11-27 10:44:04 PST
(In reply to comment #0) > We fail the Opera-submitted test at http://w3c-test.org/html/tests/submission/Opera/media/interfaces/TextTrackList/getter.html. > > The first test fails because we don't return the <track> element added to the <video> element as one of the text tracks. This happens because the <video> element is not in the document when the track was added, so HTMLTrackElement::insertedInto does not notify the HTMLMediaElement parent. Originally the parent element was always notified, but this was changed in http://trac.webkit.org/changeset/114351. I do not know why this change was made. > Note that when we do, we should respect the first rule of the spec for ordering of text tracks which says that the first items of the list are <track> elements (see http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#list-of-text-tracks). We do this, see TextTrackList::item.
Hajime Morrita
Comment 3 2012-11-27 16:04:10 PST
(In reply to comment #2) > (In reply to comment #0) > > We fail the Opera-submitted test at http://w3c-test.org/html/tests/submission/Opera/media/interfaces/TextTrackList/getter.html. > > > > The first test fails because we don't return the <track> element added to the <video> element as one of the text tracks. > > This happens because the <video> element is not in the document when the track was added, so HTMLTrackElement::insertedInto does not notify the HTMLMediaElement parent. Originally the parent element was always notified, but this was changed in http://trac.webkit.org/changeset/114351. I do not know why this change was made. This sounds like a bug. I'll take a look. Thanks for letting me know this.
Hajime Morrita
Comment 4 2012-11-27 23:27:11 PST
Dean Jackson
Comment 5 2012-11-28 07:05:08 PST
Comment on attachment 176410 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=176410&action=review > Source/WebCore/html/HTMLTrackElement.cpp:87 > void HTMLTrackElement::removedFrom(ContainerNode* insertionPoint) > { > - HTMLMediaElement* parent = mediaElement(); > - if (!parent && WebCore::isMediaElement(insertionPoint)) > - parent = toMediaElement(insertionPoint); > - if (parent) > - parent->willRemoveTrack(this); > - > + if (!parentNode() && WebCore::isMediaElement(insertionPoint)) > + toMediaElement(insertionPoint)->didRemoveTrack(this); Just checking the logic here. Previously this was calling willRemoveTrack on the parent/mediaElement() if it existed and only using the insertionPoint if there was no mediaElement(). Now it is only calling didRemoveTrack when there is no parent, and always calling it on the insertionPoint. Does this mean it is now ok for this to NOT call didRemoveTrack() when there is a parentNode()? I guess that's what the test below is testing. Sorry if I'm misunderstanding.
Dean Jackson
Comment 6 2012-11-28 07:06:44 PST
Comment on attachment 176410 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=176410&action=review > Source/WebCore/ChangeLog:27 > + (WebCore::HTMLTrackElement::insertedInto): > + (WebCore::HTMLTrackElement::removedFrom): You might want to describe what changed here.
Hajime Morrita
Comment 7 2012-11-28 23:38:14 PST
(In reply to comment #5) > > Just checking the logic here. Previously this was calling willRemoveTrack on the parent/mediaElement() if it existed and only using the insertionPoint if there was no mediaElement(). Now it is only calling didRemoveTrack when there is no parent, and always calling it on the insertionPoint. > > Does this mean it is now ok for this to NOT call didRemoveTrack() when there is a parentNode()? I guess that's what the test below is testing. Yes. If we call didRemoveTrack() even when the <track> has a parent, the <track> will be invalidated when the parent <media> or its ascent is removed from the tree. This is not desirable because we want keep <track> valid even it is not a part of the tree. Instead of that, this patch invalidates the <track> only if it is removed from its parent <media>. (In reply to comment #6) > (From update of attachment 176410 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=176410&action=review > > > Source/WebCore/ChangeLog:27 > > + (WebCore::HTMLTrackElement::insertedInto): > > + (WebCore::HTMLTrackElement::removedFrom): > > You might want to describe what changed here. Sure!
Hajime Morrita
Comment 8 2012-11-29 00:37:20 PST
Eric Carlson
Comment 9 2012-11-29 07:24:21 PST
Comment on attachment 176667 [details] Patch Thank you!
WebKit Review Bot
Comment 10 2012-11-29 07:33:52 PST
Comment on attachment 176667 [details] Patch Clearing flags on attachment: 176667 Committed r136131: <http://trac.webkit.org/changeset/136131>
WebKit Review Bot
Comment 11 2012-11-29 07:33:57 PST
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.