795784 - Can't seek in data URI video

Status: RESOLVED WORKSFORME

(Core :: Audio/Video, defect)

Description

[LBPSlava]

User Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; MDDC; InfoPath.3; .NET4.0C)

Steps to reproduce:

A working demo that ilustrates the bug, confirmed by forum users as evident in FF Windows from version 15.0.1 to current 18 nightly build, is at:

132.236.21.62/collt/authoring/currentTime.htm

There's an explanation of what the bug is at the site. Briefly, HTML5 video player does not execute the JS command VideoObject.currentTime = N where N is any number (0, 0.1, 1, etc.). In those versions of FF where this does work, this command cues the video.


Actual results:

Click Play and watch the video. When it ends, click Play or Rewind. The playhead will not move to the beginning of the video, and the video cannot be played again.


Expected results:

The video should be playable more than once.

The problem is with FF 15.0.1 and later (through 18 ightly build, according to other SUMA forum users; I test it with the released FF 15.0.1) in Windows only.

The problem is absent if you try the same site with:

FF 15 in Mac OS X, Safari 5, Chrome 5 in Mac OS X
IE 9, Chrome 21, Safari 5 in Windows

Comment 1

[LBPSlava]

Attachment: single htm file that shows the bug

Place this single htm file on any Web server, and it should demonstrate the bug with VideoObj.currentTime=N when the VideoObj is created by createElement("video") and src is assigned as base64-encoded webm clip.

I also have this demo at http://132.236.21.62/collt/authoring/currentTime.htm

Comment 2

[LBPSlava]

Thanks to cor-el at the SUMO forum for the suggestion to file the bug and also for discovering that the bug started to appear in FF 14.0.1. I have tested it with FF 13.0.1, and that version does not have this bug.

Comment 3

[LBPSlava]

Actually, I have to correct that: the bug is absent in FF 14.0.1. It seems to have been introduced in 15.0.1.

Comment 4

[Loic]

mozregression range:

m-c
good=2012-05-18
bad=2012-05-19
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e794cef56df6&tochange=642d1a36702f

Bisection needed.

Comment 5

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Reduced testcase

Comment 6

[Chris Pearce [:cpearce (Not reading bugmail)]]

The testcase is a data uri video, which I assume is somehow related to the cause of this.

Comment 7

[Alice0775 White]

Regression window(cached m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/b72c41ab1bd3
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120518095652
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/1e18c991b40c
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120518103652
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b72c41ab1bd3&tochange=1e18c991b40c

In local build:
Last Good: 5232403e7b8f
First Bad: 1e18c991b40c

Triggered by:
1e18c991b40c	Paul Adenot — Bug 756372 - Change |seeking| to prevent seeking in WebM livestream. r=kinetik

Comment 8

[Chris Pearce [:cpearce (Not reading bugmail)]]

Thanks for narrowing the regression range Alice.

Comment 9

[Lukas Blakk [:lsblakk] use ?needinfo]

(In reply to LBPSlava from comment #3)
> Actually, I have to correct that: the bug is absent in FF 14.0.1. It seems
> to have been introduced in 15.0.1.

If bug 756372 is to blame, then it should be present in 15.0 as well - can you confirm?

Comment 10

[Alex Keybl [:akeybl]]

This is a very uncommon use case and doesn't need to be tracked for release.

Comment 11

[LBPSlava]

Very uncommon use??? A video that cannot be played more than one is a tragedy. And assigning data URI is the only way to include video sourcce in the htm file. I hope Alex Keybl reconsiders. On the other hand, I don't know what "tracking for release" means, so maybe it won't affect the outcome.

Comment 12

[LBPSlava]

Correction: I misspelled "once" in "played more than once." Maybe being unable to seek a specific point in the video isn't a crucial feature, but being able to play it more than once can be crucial.

Comment 13

[Chris Pearce [:cpearce (Not reading bugmail)]]

We don't have data to say how common this use case is, or if we do I haven't seen it. I'd assume its uncommon however, since embedding data URIs of videos (particularly large ones) into HTML documents is cumbersome...

Having said that, we should be able to seek in data URIs media if the media contains all prerequisite information required to make seeking possible. And we definitely should be able to play the media more than once! This is particularly important for audio, which (I assume!) is more likely to be used in data URIs.

"Not being tracked for release" doesn't mean that it won't be worked on, it means that the people responsible for making sure none of the important bugs get forgotten won't keep an eye on the progress of this bug.

Comment 15

[Paul Adenot (:padenot)]

This is now fixed, no idea what changeset fixed it, but it works just fine (both in the original testcase and cpearce's reduced testcase).

Comment 17

[Alice0775 White]

Fixed window(m-i)
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/df91b13737cf
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20121207 Firefox/20.0 ID:20121207043851
Fixed:
http://hg.mozilla.org/integration/mozilla-inbound/rev/2b2a4f11e4ab
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20121207 Firefox/20.0 ID:20121207053050
Fixed pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=df91b13737cf&tochange=2b2a4f11e4ab

Fixed by: Bug 816949

Any chance to uplift the patch of Bug 816949 to aurora19.0a2?

Comment 18

[Paul Adenot (:padenot)]

Alice, the patch for bug 816949, caused a regression, bug 822933. I've got a patch for the regression, but we can't uplift as-is, and the reviewer is on vacations. Can can reevaluate the uplift when everything is fixed, I suppose.

Anyways, thanks for the bisection :-)

Comment 19

[bhavana bajaj [:bajaj]]

Not tracking for release as the use-case is uncommon.Although, we are happy to uplift low risk fixes on aurora based on how close we are to merging beta.

Feel free to nominate once ready, and we will consider the uplift based on risk/reward analysis.