[Webkit-unassigned] [Bug 203415] New: A visibilitychange may cause an HTMLVideoElement to reset currentTime to zero

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=203415

            Bug ID: 203415
           Summary: A visibilitychange may cause an HTMLVideoElement to
                    reset currentTime to zero
           Product: WebKit
           Version: Safari 13
          Hardware: Macintosh
                OS: macOS 10.14
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Media
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: pgoneill at gmail.com

This issue appears to be a combination of several factors that didn't fit well in the summary field:

- Live HLS with no seekable window
- A paused <video> element
- Two visibilitychange events (to hidden and back to visibile)
- Resumed playback

When these factors are combined, the currentTime reported by the HTMLVideoElement may be reset to zero or another value less than the most recently reported currentTime. I could not reproduce this on live streams that had a seekable window or when playback was not paused.

This may not be a real problem in and of itself, but it seems that in-band ID3 metadata text track's cues do not have their startTime and endTime updated to reflect the changed currentTime. The effect of this is that when this currentTime reset occurs, you may see cues firing that had already fired when they came up in the stream.


Example
-------

Here is a sample page where you can see the timing issues (though, without an ID3 track to demonstrate the issue with cues). Open the console to see debugging messages: http://solutions.brightcove.com/poneill/demos/safari-live-hls-bug/index.html


Steps to Reproduce
------------------

1. Open this sample page
2. Begin playback
3. Pause playback (note the currentTime)
4. Open a new tab, triggering visibilitychange (hidden)
5. Wait a few seconds
6. Switch back to the sample page, triggering visibilitychange (visible)
7. Resume playback (note the currentTIme)


Actual Results
--------------

After following these steps, the second currentTime was reset to zero. Cues that fired earlier may be fired again, depending on their startTime/endTime and the value to which currentTime was reset.


Expected Results
----------------

The second currentTime was unchanged or moved forward to the live edge (i.e. the number of seconds missed while playback was paused). Cues that fired earlier will not be fired again.


Version and OS
--------------

Safari 13.0.2 (14608.2.40.1.2)
macOS 10.14.6 (18G103)


Workaround
----------

In case others see this issue, we came up with a workaround: remove all cues from the in-band ID3 metadata text track whenever we see a visibilitychange event.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20191025/33dffd30/attachment-0001.htm>