User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/0.3.154.9 Safari/525.19 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081114 Minefield/3.1b2pre Using this HTML snippet throws JS exception after mousing over link a few times: <audio id="sound1"> <source src="hello.wav" type="audio/x-wav"></source> </audio> <a onmouseover="document.getElementById('sound1').currentTime=0.297984;document.getElementById('sound1').play();" onmouseout="document.getElementById('sound1').currentTime=0;document.getElementById('sound1').pause();">Mouse over me to start sound</a> Reproducible: Always Steps to Reproduce: 1. Run above HTML snippet 2. Move mouse over link a few times 3. Observe exception in error console Actual Results: Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMHTMLAudioElement.currentTime]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: file:///C:/develop/WebBased/SoundPlayback/playSoundMinefield.html :: onmouseover :: line 1" data: no] Expected Results: No exception, audio playback invariably resumes at 'currentTime'.

This happens when the Wave file ends playback. After this happens, the nsWaveStateMachine is destroyed, and is only instantiated again on play(), so an attempt to set currentTime after end results in an exception.

Start a new load in Seek() if there is no current playback state machine. Move mTimeOffset sanitization into the code that does the seek, since we might not have finished loading metadata when seek is called. Includes a testcases that passes all current tests, plus a bunch of new ones I'm in the process of submitting via other bugs. While I'm here, include a fix (and testcase) for bug 467972, since fixing that depends on fixing this anyway.

Comment on attachment 351494 [details] [diff] [review] patch v0 [Backout: Comment 4] http://hg.mozilla.org/mozilla-central/rev/cb9da8789fce after fixing context for { patching file content/media/video/test/Makefile.in Hunk #1 FAILED at 45 1 out of 2 hunks FAILED }

Comment on attachment 351494 [details] [diff] [review] patch v0 [Backout: Comment 4] Backed out: http://hg.mozilla.org/mozilla-central/rev/e8a055de467c http://hg.mozilla.org/mozilla-central/rev/7864ddfabf4a as test_wav_onloadedmetadata.html is failing. See for example: { http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1228493554.1228496655.17550.gz Linux mozilla-central moz2-linux-slave08 dep unit test on 2008/12/05 08:12:34 http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1228493734.1228498132.21564.gz MacOSX Darwin 9.2.2 mozilla-central moz2-darwin8-slave01 dep unit test on 2008/12/05 08:15:34 http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1228494161.1228497666.20719.gz WINNT 5.2 mozilla-central moz2-win32-slave07 dep unit test on 2008/12/05 08:22:41 }

Fix test failures. I wrote the test on top of the media decoder selection patch I'm working on, and forgot about the fact that it wouldn't work without that patch applied. Change the test to use the already supported <source src= type=> manual decoder selection for now. Trivial change, so no review necessary. I'm holding off on setting checkin-needed because I saw test_bug465498.html random fail on my machine, so I'm trying to track that down now.

The random failure is a timing issue. test_bug465498.html checks !v.ended in the seeked event handler after seeking to the start of the media in the ended handler. nsHTMLMediaElement's mEnded flag can still be true depending on timing, because in this situation it would only be reset when the channel called the ResourceLoaded callback. The spec doesn't explicitly say that ended should be reset, but the synchronous part of the seek sets the new currentTime, and ended can only be true when the currentTime is at the end of the media. I'll file a new bug and work on a patch. This bug will have to depend on the new one.

Trivial change from patch v1, this adds an additional check for !v.ended immediately after seeking in test_bug465498.html to make the test fail fast while bug 468190 is still present.

Same patch, but removes the test because it depends on another bug being fixed. I have a bunch of patches like this, where the testcase tests the patch but breaks because of some other bug. I'm going to open a new bug and attached a patch to that included all of the testcases, and that can land on top of the stack of bugfixes.

Comment on attachment 352675 [details] [diff] [review] patch v3 [Checkin: Comment 13 & 14] Carrying forward review.

No longer on depends bug 468190 because the tests have been split off in to bug 469268.

Comment on attachment 352675 [details] [diff] [review] patch v3 [Checkin: Comment 13 & 14] patching file content/media/video/src/nsWaveDecoder.cpp Hunk #1 FAILED at 389 Hunk #3 FAILED at 630 Hunk #4 FAILED at 1006 3 out of 4 hunks FAILED

This needs to be applied on top of bug 468190.

Comment on attachment 352675 [details] [diff] [review] patch v3 [Checkin: Comment 13 & 14] http://hg.mozilla.org/mozilla-central/rev/c062fec2a50a

Comment on attachment 352675 [details] [diff] [review] patch v3 [Checkin: Comment 13 & 14] http://hg.mozilla.org/releases/mozilla-1.9.1/rev/c3df76b205c5

Verified fix on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090420 Minefield/3.6a1pre and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090420 Shiretoko/3.5b4pre