Can't seek in data URI video

RESOLVED WORKSFORME

Status

()

RESOLVED WORKSFORME
6 years ago
6 years ago

People

(Reporter: sp27, Unassigned)

Tracking

({regression, reproducible})

15 Branch
x86
Windows 7
regression, reproducible
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox15 affected, firefox16- wontfix, firefox17-, firefox18-, firefox19-)

Details

(Whiteboard: fixed by Bug 816949, URL)

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
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
(Reporter)

Comment 1

6 years ago
Created attachment 666437 [details]
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
(Reporter)

Comment 2

6 years ago
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.
(Reporter)

Comment 3

6 years ago
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.
Summary: VideoObj.currentTime=N fails in FF 14,0,1 thru 18 Nightly build → VideoObj.currentTime=N fails in FF 15.0.1 thru 18 Nightly build

Updated

6 years ago
Attachment #666437 - Attachment mime type: text/plain → text/html

Comment 4

6 years ago
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.
Component: Untriaged → Video/Audio
Keywords: regression, regressionwindow-wanted
Product: Firefox → Core
Created attachment 666693 [details]
Reduced testcase
The testcase is a data uri video, which I assume is somehow related to the cause of this.
Summary: VideoObj.currentTime=N fails in FF 15.0.1 thru 18 Nightly build → Can't seek in data URI video

Comment 7

6 years ago
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
Blocks: 756372
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

6 years ago
status-firefox15: --- → affected
tracking-firefox16: --- → ?
tracking-firefox17: --- → ?
tracking-firefox18: --- → ?
Keywords: regressionwindow-wanted
Thanks for narrowing the regression range Alice.

Updated

6 years ago
Keywords: reproducible
(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?

Updated

6 years ago
status-firefox16: --- → wontfix
tracking-firefox16: ? → -
This is a very uncommon use case and doesn't need to be tracked for release.
tracking-firefox17: ? → -
tracking-firefox18: ? → -
(Reporter)

Comment 11

6 years ago
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.
(Reporter)

Comment 12

6 years ago
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.
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.
Blocks: 803516

Updated

6 years ago
Duplicate of this bug: 817124
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).
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME

Updated

6 years ago
Duplicate of this bug: 803516

Comment 17

6 years ago
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?
tracking-firefox19: --- → ?
Depends on: 816949
Whiteboard: fixed by Bug 816949
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 :-)
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.
tracking-firefox19: ? → -
You need to log in before you can comment on or make changes to this bug.