WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Details
Formatted Diff
Diff
Patch
(9.61 KB, patch)
2012-11-29 00:37 PST
,
Hajime Morrita
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2012-11-27 08:35:08 PST
<
rdar://problem/12758151
>
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
Created
attachment 176410
[details]
Patch
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
Created
attachment 176667
[details]
Patch
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.
Top of Page
Format For Printing
XML
Clone This Bug