2029 - Document load stalls

Status: VERIFIED DUPLICATE of bug 10736

(Core :: CSS Parsing and Computation, defect, P1)

Description

[troy]

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()

Comment 1

[Peter Linss]

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?

Comment 2

[leger]

Setting all current Open Critical and Major to M3

Comment 3

[vidur (gone)]

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. ;-)

Comment 4

[Hixie (not reading bugmail)]

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.

Comment 5

[Hixie (not reading bugmail)]

See also bug 5318.

Comment 6

[Peter Linss]

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...

Comment 7

[Peter Linss]

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.

Comment 8

[Peter Linss]

This may be as good as it gets for now. Waterson, please close this unless you
have more performance work on deck for history.

Comment 9

[Chris Waterson]

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

[Chris Waterson]

Oops. Add peterl to cc list. Peter, can you update the URL to refer to the test
case you're using? thanks.

Comment 11

[Peter Linss]

The current URL is accurate (CSS2 spec title page).

Comment 12

[troy]

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)

Comment 13

[Chris Waterson]

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?

Comment 14

[Warren Harris]

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 ***

Comment 15

[Chris Petersen]

Based on Warren's comments, marking as verified duplicated of 10736.