284587 - ###!!! ASSERTION: Trying to continue parsing on a unblocked parser.: '!(mFlags & NS_PARSER_FLAG_PARSER_ENABLED)', file r:/mozilla/parser/htmlparser/src/nsParser.cpp, line 1418

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[timeless]

bug 220542 bug 243338

CSS Error (http://www.olympic.org/common/css/style.css :66.13): Error in parsing
 value for property 'cursor'.  Declaration dropped.
Parse Time (this=08DAD1D0): Real time 0:0:0.16, CP time 0.016
DTD Time: Real time 0:0:12.375, CP time 0.813
Tokenize Time: Real time 0:0:0.16, CP time 0.016
###!!! ASSERTION: Trying to continue parsing on a unblocked parser.: '!(mFlags &
 NS_PARSER_FLAG_PARSER_ENABLED)', file
r:/mozilla/parser/htmlparser/src/nsParser.cpp, line 1418
Break: at file r:/mozilla/parser/htmlparser/src/nsParser.cpp, line 1418

 	xpcom_core.dll!nsDebug::Assertion(const char * aStr=0x02521030, const char *
aExpr=0x02521004, const char * aFile=0x02520fd4, int aLine=1418)  Line 109	C++
 	gkparser.dll!nsParser::ContinueParsing()  Line 1418 + 0x29	C++
 	gklayout.dll!CSSLoaderImpl::SheetComplete(SheetLoadData *
aLoadData=0x08894c20, int aSucceeded=1)  Line 1521	C++
 	gklayout.dll!CSSLoaderImpl::ParseSheet(nsIUnicharInputStream *
aStream=0x08945af8, SheetLoadData * aLoadData=0x08894c20, int & aCompleted=1)
 Line 1456	C++
 	gklayout.dll!SheetLoadData::OnStreamComplete(nsIUnicharStreamLoader *
aLoader=0x0883d0b0, nsISupports * aContext=0x00000000, unsigned int aStatus=0,
nsIUnicharInputStream * aDataStream=0x08945af8)  Line 801 + 0x17	C++
 	necko.dll!nsUnicharStreamLoader::OnStopRequest(nsIRequest *
request=0x06e17f60, nsISupports * ctxt=0x00000000, unsigned int aStatus=0) 
Line 196	C++
 	necko.dll!nsStreamListenerTee::OnStopRequest(nsIRequest * request=0x06e17f60,
nsISupports * context=0x00000000, unsigned int status=0)  Line 66	C++
 	necko.dll!nsHttpChannel::OnStopRequest(nsIRequest * request=0x075d9ae0,
nsISupports * ctxt=0x00000000, unsigned int status=0)  Line 3814	C++
 	necko.dll!nsInputStreamPump::OnStateStop()  Line 507	C++
 	necko.dll!nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream *
stream=0x0b7bca10)  Line 343 + 0xb	C++
 	xpcom_core.dll!nsInputStreamReadyEvent::EventHandler(PLEvent *
plevent=0x0a07c454)  Line 119	C++
 	xpcom_core.dll!PL_HandleEvent(PLEvent * self=0x0a07c454)  Line 698 + 0xa	C
 	xpcom_core.dll!PL_ProcessPendingEvents(PLEventQueue * self=0x00bce008)  Line
633 + 0x9	C
 	xpcom_core.dll!nsEventQueueImpl::ProcessPendingEvents()  Line 413 + 0xc	C++
 	gkwidget.dll!nsWindow::DispatchPendingEvents()  Line 3837	C++
 	gkwidget.dll!nsWindow::ProcessMessage(unsigned int msg=512, unsigned int
wParam=1, long lParam=786463, long * aRetValue=0x0012fc7c)  Line 4130	C++
 	gkwidget.dll!nsWindow::WindowProc(HWND__ * hWnd=0x00070cb6, unsigned int
msg=512, unsigned int wParam=1, long lParam=786463)  Line 1419 + 0x1b	C++
 	user32.dll!_InternalCallWinProc@20()  + 0x28	
 	user32.dll!_UserCallWinProcCheckWow@32()  + 0xb7	
 	user32.dll!_DispatchMessageWorker@8()  + 0xdc	
 	user32.dll!_DispatchMessageW@4()  + 0xf	
 	gkwidget.dll!nsAppShell::Run()  Line 135	C++
 	appcomps.dll!nsAppStartup::Run()  Line 207	C++
 	mozilla.exe!main1(int argc=1, char * * argv=0x00347a98, nsISupports *
nativeApp=0x00bbbfb8)  Line 1324 + 0x20	C++
 	mozilla.exe!main(int argc=1, char * * argv=0x00347a98)  Line 1825 + 0x25	C++
 	mozilla.exe!mainCRTStartup()  Line 398 + 0x11	C
 	kernel32.dll!_BaseProcessStart@4()  + 0x23	

+
{,,necko.dll}((*(nsACString*)(&(*(nsCSubstring*)(&(*(nsStandardURL*){*}(((*aLoadData).mURI).mRawPtr)).mSpec))))).mData
0x0777f240
"http://www4.mercedes-benz.com/emb/lang_select/be/css/ext_style_ie.css"	char *

Comment 1

[Blake Kaplan (:mrbkap) (inactive)]

Boris, the <link> in question here is part of the output of a document.write().
I suspect that we're blocking the parser for the <link> load and somehow
re-enable the parser before the stylesheet actually loads, but I can't support
this with code (in fact, the code seems to contradict this).

Comment 2

[Boris Zbarsky [:bzbarsky]]

Can probably check by putting breakpoints in the methods where we block and
restore the parser (after breaking the first time in the nsHTMLDocument::Write
call)...

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: patch v1

Question: How can the parser do unblocked things (like call DidBuildModel())
after being blocked?
Answer: The parser wasn't blocked.

I ran into this, and after lots and lots of thinking and breakpoints and
printf()s all over the place, I found what looks to be the culprit: we weren't
actually blocking the parser for the <link> load. Instead, we were interrupting
the parser, so when the style link loaded (successfully or not), we would try
unblocking an unblocked parser, since we'd lost the original request to block
it.

With this patch, we don't lose the request to block the parser if we hit the
magical time to interrupt.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 177268 [details] [diff] [review]
patch v1

Good catch!  sr=bzbarsky

Comment 5

[Johnny Stenback (:jst)]

Comment on attachment 177268 [details] [diff] [review]
patch v1

r=jst

Comment 6

[Blake Kaplan (:mrbkap) (inactive)]

The fix for this was checked in, accidentally, as part of my checkin for bug 285250.