Closed
Bug 471590
Opened 16 years ago
Closed 16 years ago
Crash for Wav when seeking and onunload() pauses [@ nsHTMLMediaElement::Pause]
Categories
(Core :: Audio/Video, defect, P2)
Tracking
()
VERIFIED
FIXED
People
(Reporter: cpearce, Assigned: kinetik)
Details
(Keywords: crash, verified1.9.1)
Crash Data
Attachments
(2 files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
cajbir
:
review+
roc
:
superreview+
|
Details | Diff | Splinter Review |
If you have a <video src="some_wav"> in a page with an onunload() which pauses the <video>, you can crash the browser if you play the wav and seek while the wav is still playing and you close the browser. Before the crash, I also see the error:
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80470002: file c:/work/src/orange/content/media/video/src/nsChannelToPipeListener.cpp, line 182
Stack:
gklayout.dll!nsHTMLMediaElement::Pause() Line 396 C++
gklayout.dll!nsHTMLVideoElement::Pause() Line 61 + 0xc bytes C++
xpcom_core.dll!NS_InvokeByIndex_P(nsISupports * that=0x00000047, unsigned int methodIndex=0, unsigned int paramCount=1428944, nsXPTCVariant * params=0x0000408d) Line 102 C++
xpc3250.dll!XPCWrappedNative::CallMethod(XPCCallContext & ccx={...}, XPCWrappedNative::CallMode mode=71) Line 2424 + 0x21 bytes C++
xpc3250.dll!XPCWrappedNative::CallMethod(XPCCallContext & ccx={...}, XPCWrappedNative::CallMode mode=CALL_METHOD) Line 2424 + 0x21 bytes C++
xpc3250.dll!XPC_WN_CallMethod(JSContext * cx=0x040348e8, JSObject * obj=0x07123d00, unsigned int argc=0, long * argv=0x045a3f9c, long * vp=0x0015d0a0) Line 1477 + 0xe bytes C++
js3250.dll!js_Invoke(JSContext * cx=0x040348e8, unsigned int argc=0, long * vp=0x045a3f94, unsigned int flags=2) Line 1318 + 0x1a bytes C++
js3250.dll!js_Interpret(JSContext * cx=0x040348e8) Line 5013 + 0x16 bytes C++
js3250.dll!js_Invoke(JSContext * cx=0x040348e8, unsigned int argc=1, long * vp=0x045a3f0c, unsigned int flags=0) Line 1336 + 0x9 bytes C++
js3250.dll!js_InternalInvoke(JSContext * cx=0x040348e8, JSObject * obj=0x071231e0, long fval=118635584, unsigned int flags=0, unsigned int argc=1, long * argv=0x045a3f08, long * rval=0x0015d9cc) Line 1393 + 0x15 bytes C++
js3250.dll!JS_CallFunctionValue(JSContext * cx=0x040348e8, JSObject * obj=0x071231e0, long fval=118635584, unsigned int argc=1, long * argv=0x045a3f08, long * rval=0x0015d9cc) Line 5247 + 0x1f bytes C++
gklayout.dll!nsJSContext::CallEventHandler(nsISupports * aTarget=0x045e86e0, void * aScope=0x071231e0, void * aHandler=0x07123c40, nsIArray * aargv=0x04203f08, nsIVariant * * arv=0x0015db98) Line 1987 + 0x21 bytes C++
gklayout.dll!nsJSEventListener::HandleEvent(nsIDOMEvent * aEvent=0x04114b00) Line 247 + 0x67 bytes C++
gklayout.dll!nsEventListenerManager::HandleEventSubType(nsListenerStruct * aListenerStruct=0x05e36918, nsIDOMEventListener * aListener=0x05e9e550, nsIDOMEvent * aDOMEvent=0x04114b00, nsPIDOMEventTarget * aCurrentTarget=0x0373abd0, unsigned int aPhaseFlags=6) Line 1090 + 0x12 bytes C++
gklayout.dll!nsEventListenerManager::HandleEvent(nsPresContext * aPresContext=0x043ea228, nsEvent * aEvent=0x0015df44, nsIDOMEvent * * aDOMEvent=0x0015dea0, nsPIDOMEventTarget * aCurrentTarget=0x0373abd0, unsigned int aFlags=6, nsEventStatus * aEventStatus=0x0015dea4) Line 1197 C++
gklayout.dll!nsEventTargetChainItem::HandleEvent(nsEventChainPostVisitor & aVisitor={...}, unsigned int aFlags=6, int aMayHaveNewListenerManagers=1) Line 228 C++
gklayout.dll!nsEventTargetChainItem::HandleEventTargetChain(nsEventChainPostVisitor & aVisitor={...}, unsigned int aFlags=6, nsDispatchingCallback * aCallback=0x00000000, int aMayHaveNewListenerManagers=1) Line 293 C++
gklayout.dll!nsEventDispatcher::Dispatch(nsISupports * aTarget=0x0373ab90, nsPresContext * aPresContext=0x043ea228, nsEvent * aEvent=0x0015df44, nsIDOMEvent * aDOMEvent=0x00000000, nsEventStatus * aEventStatus=0x0015df40, nsDispatchingCallback * aCallback=0x00000000) Line 508 + 0x14 bytes C++
gklayout.dll!DocumentViewerImpl::PageHide(int aIsUnload=1) Line 1191 + 0x21 bytes C++
docshell.dll!nsDocShell::FirePageHideNotification(int aIsUnload=1) Line 1035 C++
docshell.dll!nsDocShell::FirePageHideNotification(int aIsUnload=1) Line 1047 C++
docshell.dll!nsDocShell::Destroy() Line 3719 C++
appshell.dll!nsXULWindow::Destroy() Line 507 C++
appshell.dll!nsWebShellWindow::Destroy() Line 866 + 0x9 bytes C++
appshell.dll!nsWebShellWindow::HandleEvent(nsGUIEvent * aEvent=0x0015e33c) Line 420 C++
gkwidget.dll!nsWindow::DispatchEvent(nsGUIEvent * event=0x0015e33c, nsEventStatus & aStatus=nsEventStatus_eIgnore) Line 963 + 0xc bytes C++
gkwidget.dll!nsWindow::DispatchWindowEvent(nsGUIEvent * event=0x0015e33c) Line 984 C++
gkwidget.dll!nsWindow::DispatchStandardEvent(unsigned int aMsg=101) Line 1003 + 0x11 bytes C++
gkwidget.dll!nsWindow::ProcessMessage(unsigned int msg=16, unsigned int wParam=0, long lParam=0, long * aRetValue=0x0015e844) Line 4325 C++
gkwidget.dll!nsWindow::WindowProc(HWND__ * hWnd=0x00060616, unsigned int msg=16, unsigned int wParam=0, long lParam=0) Line 1173 + 0x1d bytes C++
Looks to me like the nsHTMLMediaElement::Pause() is causing a reload which is nulling out the old decoder, which is then having pause() called on it - on a null ref.
I only see this crash when playing a WAV, not when playing an OGG video.
Severity: normal → critical
Keywords: crash
Summary: Crash for Wav when seeking and onunload() pauses → Crash for Wav when seeking and onunload() pauses [@ nsHTMLMediaElement::Pause]
Assignee | ||
Comment 1•16 years ago
|
||
It looks like Pause() wasn't updated to handle the asynchronous loading. I reviewed the callers of Load() at the time I made that change, but somehow I missed this. Change it to either kick off a new load or pause the existing decoder.
Also, it turned out we were getting into this state because NetworkError() was fired spuriously when seeking. When the range request is kicked off, the existing channel is closed. Eventually the listener's OnStopRequest() would be called with NS_BASE_STREAM_CLOSED (caused by the pipe being closed in the stream strategy's Close() method).
While here, also change the listener's OnDataAvailable() to use NS_FAILED with a return rather than NS_ENSURE_SUCCESS, to avoid a warning once we hit reach the end of the pipe. I don't think we should log a warning here (via NS_ENSURE_SUCCESS), since it's something we expect to happen after seeking.
No test included because I couldn't work out how to test this reliably.
Assignee: nobody → kinetik
Status: NEW → ASSIGNED
Attachment #355675 -
Flags: superreview?(roc)
Attachment #355675 -
Flags: review?(chris.double)
Updated•16 years ago
|
Attachment #355675 -
Flags: review?(chris.double) → review+
Attachment #355675 -
Flags: superreview?(roc) → superreview+
Assignee | ||
Updated•16 years ago
|
Flags: blocking1.9.1?
Updated•16 years ago
|
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
Assignee | ||
Updated•16 years ago
|
Keywords: checkin-needed
Pushed 28488df9e75e
Assignee | ||
Updated•16 years ago
|
Whiteboard: [baking for 1.9.1]
Whiteboard: [baking for 1.9.1] → [needs 191 landing]
Keywords: fixed1.9.1
Whiteboard: [needs 191 landing]
Comment 4•16 years ago
|
||
Verified fixed on the 1.9.1 branch using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090304 Shiretoko/3.1b3pre and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090303 Shiretoko/3.1b3pre.
Verified fixed on the trunk using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090304 Minefield/3.2a1pre and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090304 Minefield/3.2a1pre.
No crash or error in the console.
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
Updated•13 years ago
|
Crash Signature: [@ nsHTMLMediaElement::Pause]
You need to log in
before you can comment on or make changes to this bug.
Description
•