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: 22.214.171.124/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
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://126.96.36.199/collt/authoring/currentTime.htm
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.
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
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
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
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
status-firefox15: --- → affected
tracking-firefox16: --- → ?
tracking-firefox17: --- → ?
tracking-firefox18: --- → ?
Thanks for narrowing the regression range Alice.
(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?
This is a very uncommon use case and doesn't need to be tracked for release.
tracking-firefox17: ? → -
tracking-firefox18: ? → -
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.
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.
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
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.