According to spec [1], oncuechange is one of the GlobalEventHandler. This event could be fired on Track element or TextTrack [2].

We would dispatch this event when we run the TimeMarchesOn algorithm. [3]

[1] https://html.spec.whatwg.org/multipage/webappapis.html#handler-oncuechange
[2] https://html.spec.whatwg.org/multipage/media.html#event-media-cuechange
[3] https://html.spec.whatwg.org/multipage/media.html#playing-the-media-resource:event-media-cuechange

According to the spec [1], oncuechange is one of the GlobalEventHandler. This event could be fired on Track element or TextTrack [2].

We would dispatch this event when we run the TimeMarchesOn algorithm.

[1] https://html.spec.whatwg.org/multipage/webappapis.html#handler-oncuechange
[2] https://html.spec.whatwg.org/multipage/media.html#event-media-cuechange
[3] https://html.spec.whatwg.org/multipage/media.html#playing-the-media-resource:event-media-cuechange

Now I'm investigating why track-mode.html and track-cues-cuechange.html will fail intermittently, will start a review after figuring out the reason.

This patch does two changes in order to test the correct behavior.

(1) Not to use time out function
Waiting for 0.4s by using timeout function doesn't mean the code will exactly be executed after 0.4s.
If we would like to specify the time when we should change track's mode, we should listen for video's timeupdate to get the correct result.

(2) Modify ending condition
As this test is going to turn the track to showing/hidden after video is playing after 0.4s, the second and the third cue would be showed correctly.

The second cue is from 0.3 to 0.7, so when we changed track mode in 0.4s, it would be regard as a active cue, and dispatch enter. When the cue is going to become inactive, the event exit would be dispatched.

Therefore, there would be total 4 times of the accumulation of enter and exit events, which means oncuechange would also be dispatched 4 times.

The track-cues-cuechange.html would only fail on the Win32 on try, I guess there might be some playback issue on Windows which causes the failure. I'm going to disable that test on Win32, but enable it on other platforms.

https://hg.mozilla.org/mozilla-central/rev/073a5c5c2262
https://hg.mozilla.org/mozilla-central/rev/cea220a6b7dd
https://hg.mozilla.org/mozilla-central/rev/304294b29dae

We previously had this documenting as being implemented already in Firefox 31. I'm not sure why...

(In reply to Eric Shepherd [:sheppy] from comment #10)

We previously had this documenting as being implemented already in Firefox 31. I'm not sure why...

The MDN document is the cuechange event [1] for text track, but in this bug, what we implemented is the cuechange event for track element [2].

[1] https://developer.mozilla.org/en-US/docs/Web/API/TextTrack/cuechange_event
[2] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/track

Oh! Gotcha! I missed that bit when doing a quick once-over of the bug. I'm on it then. :)

Documentation updates:

• Updated TextTrack cuechange event
• Added cuechange event to HTMLTrackElement
• Created page for HTMLTrackElement's cuechange event which simply embeds the contents of the article on TextTrack's cuechange event
• Added cuechange event to <track> and HTMLTrackElement in BCD
• Submitted BCD PR 4400 with cuechange updates
• Added an entry on Firefox 68 for developers