Intent to Deprecate: TextTrackCue constructor

539 views
Skip to first unread message

Philip Jägenstedt

unread,
Jan 15, 2014, 9:56:56 AM1/15/14
to blink-dev

Primary eng (and PM) emails

phi...@opera.com

Summary

Deprecate the TextTrackCue constructor, which has been removed from spec.

Motivation

When adding VTTCue the TextTrackCue constructor was left for backwards compat pending proof that it could be removed. It has non-trivial custom V8 code to handle the fact that the constructor returns another type than itself, which has caused a memory leak. (That was my fault.)

Usage information from UseCounter

The TextTrackCueConstructor use counter was among those listed in <http://crbug.com/332191>. The counter has reached beta.

Compatibility Risk

Scripts creating TextTrackCues using new TextTrackCue(...) will break. Mostly demos are likely to be affected. It is trivially fixed by using the VTTCue constructor instead.

Row on feature dashboard?

No

Requesting approval to remove too?

No, wait for data from the stable channel, which is very likely to be in support of removal.

Jochen Eisinger

unread,
Jan 15, 2014, 10:00:36 AM1/15/14
to Philip Jägenstedt, blink-dev

Does the VVTCue constructor now also return a VTTCue object?

Glenn Adams

unread,
Jan 15, 2014, 10:31:30 AM1/15/14
to Jochen Eisinger, Philip Jägenstedt, blink-dev
lgtm


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Philip Jägenstedt

unread,
Jan 15, 2014, 11:50:39 AM1/15/14
to Jochen Eisinger, blink-dev
Yes, the VTTCue constructor is per spec and does what you'd expect: return a new VTTCue object.

Philip

Jochen Eisinger

unread,
Jan 15, 2014, 11:52:20 AM1/15/14
to Philip Jägenstedt, blink-dev

lgtm

Adam Barth

unread,
Jan 15, 2014, 12:47:41 PM1/15/14
to Philip Jägenstedt, blink-dev
On Wed, Jan 15, 2014 at 6:56 AM, Philip Jägenstedt <phi...@opera.com> wrote:

Primary eng (and PM) emails

phi...@opera.com

Summary

Deprecate the TextTrackCue constructor, which has been removed from spec.

Motivation

When adding VTTCue the TextTrackCue constructor was left for backwards compat pending proof that it could be removed. It has non-trivial custom V8 code to handle the fact that the constructor returns another type than itself, which has caused a memory leak. (That was my fault.)

Usage information from UseCounter

The TextTrackCueConstructor use counter was among those listed in <http://crbug.com/332191>. The counter has reached beta.

According to that use counter, TextTrackCueConstructor is used on 0.0013% of page views.

Adam

Ojan Vafai

unread,
Jan 15, 2014, 1:05:12 PM1/15/14
to Adam Barth, Philip Jägenstedt, blink-dev
lgtm

TAMURA, Kent

unread,
Jan 15, 2014, 8:20:27 PM1/15/14
to Ojan Vafai, Adam Barth, Philip Jägenstedt, blink-dev
lgtm.
--
TAMURA Kent
Software Engineer, Google


Philip Jägenstedt

unread,
Jan 15, 2014, 11:05:08 PM1/15/14
to TAMURA, Kent, Ojan Vafai, Adam Barth, blink-dev
Thanks all!

Review is up at https://codereview.chromium.org/139303007/

ruben.v...@gmail.com

unread,
Jan 17, 2014, 2:30:25 PM1/17/14
to blin...@chromium.org, TAMURA, Kent, Ojan Vafai, Adam Barth
Hi all,

I'm using the TextTrackCue in an application at the moment.
How should I replace this (and when will I be able to do this)?

Best,

Ruben

PhistucK

unread,
Jan 17, 2014, 3:06:42 PM1/17/14
to ruben.v...@gmail.com, blink-dev, TAMURA, Kent, Ojan Vafai, Adam Barth
The first post states -

Compatibility Risk

Scripts creating TextTrackCues using new TextTrackCue(...) will break. Mostly demos are likely to be affected. It is trivially fixed by using the VTTCue constructor instead.

So I guess you should use the VTTCue constructor instead. 


PhistucK


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

ruben.v...@gmail.com

unread,
Jan 17, 2014, 3:09:41 PM1/17/14
to blin...@chromium.org, ruben.v...@gmail.com, TAMURA, Kent, Ojan Vafai, Adam Barth
So I guess you should use the VTTCue constructor instead. 

The problem is this doesn't work (yet?):

console.log(typeof TextTrackCue, typeof VTTCue);
// function undefined 

So I can't reliably switch yet. When could/should I make the switch?

PhistucK

unread,
Jan 17, 2014, 3:32:26 PM1/17/14
to ruben.v...@gmail.com, blink-dev, TAMURA, Kent, Ojan Vafai, Adam Barth
I guess Chrome 33 (approximately less than six weeks from now, or currently in beta, or any latest Chrome 34 canary build) or later?
Though, I do not see three "LGTM"s there (but only two and I have not read the thread again in order to read more verbal "LGTM" statements), the main concern (the specification fork) was resolved since then -
So I can only guess Glenn went ahead with the implementation or something.

Though this does not matter much (because it would probably be changed accordingly, to match reality), the specification does not state that it is a "[NoInterfaceObject]", so I guess the intention of the implementation is to change the specification.


PhistucK


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Glenn Adams

unread,
Jan 17, 2014, 3:42:51 PM1/17/14
to PhistucK, ruben.v...@gmail.com, blink-dev, TAMURA, Kent, Ojan Vafai, Adam Barth
On Fri, Jan 17, 2014 at 1:32 PM, PhistucK <phis...@gmail.com> wrote:
I guess Chrome 33 (approximately less than six weeks from now, or currently in beta, or any latest Chrome 34 canary build) or later?
Though, I do not see three "LGTM"s there (but only two and I have not read the thread again in order to read more verbal "LGTM" statements), the main concern (the specification fork) was resolved since then -
So I can only guess Glenn went ahead with the implementation or something.

Though this does not matter much (because it would probably be changed accordingly, to match reality), the specification does not state that it is a "[NoInterfaceObject]", so I guess the intention of the implementation is to change the specification.

Both TextTrackCue [1] and VTTCue [2] are specified so as to provide an interface object. So I'm not sure what you imply by "change the specification".


ToT in Blink exposes both interface objects, as well as constructors for both, now deprecating the constructor for TextTrackCue. I can't comment on shipping status, but perhaps PhilipJ will elaborate.

PhistucK

unread,
Jan 17, 2014, 3:48:29 PM1/17/14
to Glenn Adams, ruben.v...@gmail.com, blink-dev, TAMURA, Kent, Ojan Vafai, Adam Barth
Exactly, currently the specification defines a constructor for TextTrackCue (meaning, there is no "[NoInterfaceObject]" IDL attribute on the interface. If I understand correctly, having a "[NoInterfaceObject]" IDL attribute on a "Foo" interface makes it non constructible using "new Foo()").

So, if I indeed understood correctly, the deprecation of the TextTrackCue means that the TextTrackCue interface should have a "[NoInterfaceObject]" IDL attribute, which means, the specification would change, since it does not have it now.

Feel free to correct me.


PhistucK

PhistucK

unread,
Jan 17, 2014, 3:53:54 PM1/17/14
to Glenn Adams, Ruben Verborgh, blink-dev, TAMURA, Kent, Ojan Vafai, Adam Barth
I will do the correcting myself. :)
Only a Foo interface with a "[Constructor]" IDL attributes can be constructed by "new Foo()".
While "[NoInterfaceObject]" implies it as well (since there is no object, so you cannot construct it), it is not the appropriate IDL attribute for stating that an interface is non constructible.

So the specification does not need to change. Sorry for the noise.


PhistucK

Glenn Adams

unread,
Jan 17, 2014, 4:11:01 PM1/17/14
to PhistucK, Ruben Verborgh, blink-dev, TAMURA, Kent, Ojan Vafai, Adam Barth
Even though the interface prototype object of an interface specified without [NoInterfaceObject] must have a constructor property whose value is an interface object that is a function object, it does not necessarily follow that the function object returns an object upon [[Call]]. In particular, see WebIDL [1] (emphasis added):

"If the interface is declared with a [Constructor] extended attribute, then the interface object can be called as a function to create an object that implements that interface. Interfaces that do not have a constructor will throw an exception when called as a function."

PhistucK

unread,
Jan 17, 2014, 4:14:33 PM1/17/14
to Glenn Adams, Ruben Verborgh, blink-dev, TAMURA, Kent, Ojan Vafai, Adam Barth
Yep. I figured that out already. :)


PhistucK

Philip Jägenstedt

unread,
Jan 17, 2014, 9:17:53 PM1/17/14
to ruben.v...@gmail.com, blink-dev
In order to work both in browsers which have added VTTCue and those
which haven't, you'll need to try both.

To make a local change only, replace

new TextTrackCue(0, 0, '')

with

new (window.VTTCue || window.TextTrackCue)(0, 0, '')

However, if you create TextTrackCues in multiple places and want
cleaner code, I would define VTTCue as an alias of TextTrackCue
globally:

if (!window.VTTCue) window.VTTCue = window.TextTrackCue;

Then you can just use new VTTCue(0, 0, '').

Hope that helps!

Philip

ruben.v...@gmail.com

unread,
Jan 18, 2014, 5:51:45 AM1/18/14
to blin...@chromium.org, ruben.v...@gmail.com
Yes that helps, thanks!

Ruben

pdc...@gmail.com

unread,
Jun 28, 2017, 9:58:35 AM6/28/17
to blink-dev, phi...@opera.com
This works great, until you try to remove the cue.  Unfortunately, the removeCue() function only takes at TextTrackCue object as a parameter, so when you try to remove a VVTCue it throws an exception : 

Failed to execute 'removeCue' on 'TextTrack': parameter 1 is not of type 'TextTrackCue'

Fredrik Söderquist

unread,
Jun 28, 2017, 10:07:58 AM6/28/17
to pdc...@gmail.com, blink-dev, Philip Jägenstedt
On Wed, Jun 28, 2017 at 3:58 PM, <pdc...@gmail.com> wrote:
This works great, until you try to remove the cue.  Unfortunately, the removeCue() function only takes at TextTrackCue object as a parameter, so when you try to remove a VVTCue it throws an exception : 

Failed to execute 'removeCue' on 'TextTrack': parameter 1 is not of type 'TextTrackCue'

Could you file a bug at crbug.com/new? (A VTTCue is still a TextTrackCue, so this a bit odd - and addCue has the same signature. And there are tests for this case...)


/fs


On Wednesday, January 15, 2014 at 9:56:56 AM UTC-5, Philip Jägenstedt wrote:

Primary eng (and PM) emails

phi...@opera.com

Summary

Deprecate the TextTrackCue constructor, which has been removed from spec.

Motivation

When adding VTTCue the TextTrackCue constructor was left for backwards compat pending proof that it could be removed. It has non-trivial custom V8 code to handle the fact that the constructor returns another type than itself, which has caused a memory leak. (That was my fault.)

Usage information from UseCounter

The TextTrackCueConstructor use counter was among those listed in <http://crbug.com/332191>. The counter has reached beta.

Compatibility Risk

Scripts creating TextTrackCues using new TextTrackCue(...) will break. Mostly demos are likely to be affected. It is trivially fixed by using the VTTCue constructor instead.

Row on feature dashboard?

No

Requesting approval to remove too?

No, wait for data from the stable channel, which is very likely to be in support of removal.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e0cc3183-eaf3-4686-a503-85ee3c328b0d%40chromium.org.

Reply all
Reply to author
Forward
0 new messages