Closed
Bug 284587
Opened 19 years ago
Closed 19 years ago
###!!! 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
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: timeless, Assigned: mrbkap)
References
()
Details
(Keywords: assertion)
Attachments
(1 file)
1.62 KB,
patch
|
jst
:
review+
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
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 *
Assignee | ||
Comment 1•19 years ago
|
||
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•19 years ago
|
||
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)...
Assignee | ||
Comment 3•19 years ago
|
||
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.
Assignee: dbaron → mrbkap
Status: UNCONFIRMED → ASSIGNED
Assignee | ||
Updated•19 years ago
|
Attachment #177268 -
Flags: superreview?(bzbarsky)
Attachment #177268 -
Flags: review?(jst)
Comment 4•19 years ago
|
||
Comment on attachment 177268 [details] [diff] [review] patch v1 Good catch! sr=bzbarsky
Attachment #177268 -
Flags: superreview?(bzbarsky) → superreview+
Comment 5•19 years ago
|
||
Comment on attachment 177268 [details] [diff] [review] patch v1 r=jst
Attachment #177268 -
Flags: review?(jst) → review+
Assignee | ||
Comment 6•19 years ago
|
||
The fix for this was checked in, accidentally, as part of my checkin for bug 285250.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•