Closed
Bug 2029
Opened 26 years ago
Closed 25 years ago
Document load stalls
Categories
(Core :: CSS Parsing and Computation, defect, P1)
Tracking
()
M12
People
(Reporter: troy, Assigned: warrensomebody)
References
()
Details
(Whiteboard: Waiting for improvements in history performance)
NTDLL! 77f76148() nsDebug::Assertion(const char * 0x0049428c ??_C@_0CK@IGKJ@change?5your?5code?5to?5use?5the?5Equa@, const char * 0x004942b8 ?? :: ?? :: ?? ::PLJA::PLJA ?? `string', const char * 0x004942bc ??_C@_0BD@GA@?4?4?2public?2nsIURL?4h?$AA@, int 43) line 95 + 13 bytes nsIURL::operator==(const nsIURL & {...}) line 43 + 32 bytes CSSStyleSheetImpl::ContainsStyleSheet(nsIURL * 0x0146a560) line 1494 + 29 bytes CSSParserImpl::ProcessImport(int & 0, const nsString & {"style/default.css"}, const nsString & {""}) line 731 + 21 bytes CSSParserImpl::ParseImportRule(int & 0) line 609 CSSParserImpl::ParseAtRule(int & 0) line 535 CSSParserImpl::Parse(CSSParserImpl * const 0x0146a9a0, nsIUnicharInputStream * 0x0146aa60, nsIURL * 0x00f0d980, nsICSSStyleSheet * & 0x00000000) line 336 HTMLContentSink::LoadStyleSheet(nsIURL * 0x00f0d980, nsIUnicharInputStream * 0x0146aa60, int 1, const nsString & {""}, const nsString & {""}, nsIHTMLContent * 0x0146ad3c) line 2703 HTMLContentSink::ProcessSTYLETag(const nsIParserNode & {...}) line 2557 + 39 bytes HTMLContentSink::AddLeaf(HTMLContentSink * const 0x00f15c60, const nsIParserNode & {...}) line 1810 + 12 bytes CNavDTD::AddLeaf(const nsIParserNode & {...}) line 2954 + 22 bytes CNavDTD::HandleStartToken(CToken * 0x00f84460) line 917 + 15 bytes NavDispatchTokenHandler(CToken * 0x00f84460, nsIDTD * 0x00f86680) line 446 + 12 bytes CTokenHandler::operator()(CToken * 0x00f84460, nsIDTD * 0x00f86680) line 80 + 14 bytes CNavDTD::HandleToken(CNavDTD * const 0x00f86680, CToken * 0x00f84460, nsIParser * 0x00f14b80) line 697 + 18 bytes nsParser::BuildModel() line 765 + 20 bytes nsParser::ResumeParse() line 723 + 11 bytes nsParser::EnableParser(int 1) line 596 HTMLContentSink::ResumeParsing() line 2323 nsDoneLoadingStyle(nsIUnicharStreamLoader * 0x00fa7b40, nsString & {"/* * Style sheet for the CSS2 specification * $Id: default.css,v 2.14 1998/03/24 16:16:22 bbos Exp $ */ BODY { color: "}, void * 0x00fa7bd0, unsigned int 0) line 2109 nsUnicharStreamLoader::OnStopBinding(nsUnicharStreamLoader * const 0x00fa7b44, nsIURL * 0x00fa7db0, unsigned int 0, const unsigned short * 0x00fa7a40) line 148 + 31 bytes OnStopBindingProxyEvent::HandleEvent(OnStopBindingProxyEvent * const 0x00fa6120) line 575 StreamListenerProxyEvent::HandlePLEvent(PLEvent * 0x00fa6124) line 453 + 12 bytes PL_HandleEvent(PLEvent * 0x00fa6124) line 395 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00eb9810) line 357 + 9 bytes _md_EventReceiverProc(HWND__ * 0xc46f0240, unsigned int 49308, unsigned int 0, long 15439888) line 675 + 9 bytes USER32! 77e71250() 00eb9810()
Updated•26 years ago
|
Assignee: peterl → vidur
Summary: Assert in ContainsStyleSheet() → Document load stalls
Comment 1•26 years ago
|
||
The assertion has been fixed. But now this page (and several others in the CSS1 test spec) seems to stall on document load. I don't know if this is a netlib cache issue of a problem in the async loading code. Vidur, can you please take a look?
Updated•26 years ago
|
Assignee: vidur → peterl
Comment 3•26 years ago
|
||
There are 2 problems with this document: 1) Construction and layout of this document is especially slow. I put a break in the code that loads the style sheet and the loading completes reasonably quickly. There seems to be a long delay, however, after we load the style sheet and before we see anything. I tried breaking several times during that delay and found that we were in frame construction code, often with style resolution happening at the top of the stack. I suspect that this code is even slower since we delete existing frames once the new style sheet comes in. 2) Netlib seems to be ignoring the result code from stream methods. Specifically, the process of deleting frames once the new style sheet comes in interrupts image loading. The interrupted image consumer returns an error value of MK_INTERRUPTED from its OnDataAvailable() method and never reads from the stream again. Netlib doesn't seem to interpret this as the end of the line and still keeps the stream alive. Of course, no one is reading from the other end of the stream, so the loading animation continues indefinitely. Note that this is highly timing dependent (it won't happen if the image loads before the style sheet). The first problem is something that Peter should probably look at. The second is probably Gagan's problem and may warrant a second bug. I'll leave that up to you Peter. ;-)
Updated•26 years ago
|
QA Contact: 4110 → 4144
Comment 4•26 years ago
|
||
This bug will probably be fixed by Peter forthcoming stylesheet manager class. Related bugs: bug 2029, bug 2765, bug 3421, bug 4529. To find related bugs, search the description field for the [SSMC] marker.
Updated•26 years ago
|
Target Milestone: M5 → M6
Updated•26 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M6 → M8
Comment 6•26 years ago
|
||
The delay isn't a sheet load issue. There's a problem where due to the large number of links, a large nuber of style contexts are (unnecessarily) being created. I have a fix in mind...
Updated•26 years ago
|
Target Milestone: M8 → M9
Comment 7•26 years ago
|
||
Partial fix checked in. We now create a whole lot less style contexts for this page (and many like it). Unfortunately, the code to determine whether a link has been visited is dog slow. I'm going to spank that next.
Updated•26 years ago
|
Whiteboard: Waiting for improvements in history performance
Target Milestone: M9 → M10
Updated•25 years ago
|
Assignee: peterl → waterson
Status: ASSIGNED → NEW
Comment 8•25 years ago
|
||
This may be as good as it gets for now. Waterson, please close this unless you have more performance work on deck for history.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M10 → M12
Comment 9•25 years ago
|
||
Peter, can you point me to the page that you're using to test stuff? I've replaced the history back-end with what should be its final implementation; however, I haven't done any tuning at all. I can go ahead and take a pass through the history back-end to pick up any slack there.
Comment 10•25 years ago
|
||
Oops. Add peterl to cc list. Peter, can you update the URL to refer to the test case you're using? thanks.
Reporter | ||
Comment 12•25 years ago
|
||
Peter, I noticed in my Quantify runs this week the same thing, that NS_MakeAbsoluteURL is probably the slowest routine on the face of the earth I'm interested in solving that problem as well, so I'll give you a call and see what we can do about it (either get Necko to speed it up, or find a faster alternative)
Updated•25 years ago
|
Assignee: waterson → warren
Status: ASSIGNED → NEW
Comment 13•25 years ago
|
||
Ok, so the big problem here seems to be NS_MakeAbsoluteURL(). Warren, I'm giving this love to you: can you profile and improve performance?
Assignee | ||
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Comment 14•25 years ago
|
||
If there's more to this bug than MakeAbsolute performance, please reopen. Otherwise this is a dup. *** This bug has been marked as a duplicate of 10736 ***
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•