55905 - zing page locks up browser for 15-20 seconds

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P3)

Description

[Alec Flett]

for some reason the above URL really locks up the browser hard while it's laying
out - and it takes a long time to lay out, and it doesn't even layout the whole
page (though that may be zing's problem) - the page is NOT large at all.

(this is on the Netscape branch, haven't tried the tip yet)

Comment 1

[Kurt Weinschenker]

Hmmm.  Tried on Mac OS 9.0.4 with build 2000100720-M18 in a new window.

Page hung until I bounced back to my original window, and then bounced back.
Mozilla reported the page load time as 29.489 secs.  But there was no program
crash, just a mis-laidout page.

Comment 2

[harishd]

Taking 5 of clayton's for triaging.

Comment 3

[harishd]

We are spending a lot of time here:

Compare2To2(const char * 0x00ff0f14, const char * 0x0012f698, unsigned int 8, 
int 1) line 621
nsStr::RFindSubstr(const nsStr & {...}, const nsStr & {...}, int 1, int 39558, 
int 36846) line 540 + 43 bytes
nsString::RFind(const nsString & {"</script"}, int 1, int 39558, int 36846) line 
1253 + 73 bytes
CTextToken::ConsumeUntil(unsigned short 0, int 0, nsScanner & {...}, nsString & 
{"</script"}, int 1, int & 0) line 643 + 31 bytes
nsHTMLTokenizer::ConsumeStartTag(unsigned short 76, CToken * & 0x00fd9208, 
nsScanner & {...}, int & 0) line 709 + 45 bytes
nsHTMLTokenizer::ConsumeTag(unsigned short 83, CToken * & 0x00fd9208, nsScanner 
& {...}, int & 0) line 531 + 34 bytes
nsHTMLTokenizer::ConsumeToken(nsScanner & {...}, int & 0) line 459 + 34 bytes
nsParser::Tokenize(int 0) line 2453 + 28 bytes
nsParser::ResumeParse(int 1, int 0) line 1889 + 12 bytes
nsParser::EnableParser(int 1) line 1527 + 15 bytes
HTMLContentSink::ResumeParsing() line 4560 + 19 bytes
HTMLContentSink::OnStreamComplete(HTMLContentSink * const 0x03681464, 
nsIStreamLoader * 0x03428e70, nsISupports * 0x00000000, unsigned int 0, unsigned 
int 1026, const char * 0x00f42028) line 4757 + 11 bytes
nsStreamLoader::OnStopRequest(nsStreamLoader * const 0x03428e74, nsIChannel * 
0x03428c90, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 
0x002d56c8 gCommonEmptyBuffer) line 121 + 78 bytes
nsHTTPFinalListener::OnStopRequest(nsHTTPFinalListener * const 0x034289a0, 
nsIChannel * 0x03428c90, nsISupports * 0x00000000, unsigned int 0, const 
unsigned short * 0x002d56c8 gCommonEmptyBuffer) line 1158 + 42 bytes
InterceptStreamListener::OnStopRequest(InterceptStreamListener * const 
0x0342b610, nsIChannel * 0x03428c90, nsISupports * 0x00000000, unsigned int 0, 
const unsigned short * 0x002d56c8 gCommonEmptyBuffer) line 1207
nsHTTPChannel::ResponseCompleted(nsIStreamListener * 0x0342b610, unsigned int 0, 
const unsigned short * 0x002d56c8 gCommonEmptyBuffer) line 1895 + 42 bytes
nsHTTPServerListener::OnStopRequest(nsHTTPServerListener * const 0x0342b060, 
nsIChannel * 0x03429cd4, nsISupports * 0x03428c90, unsigned int 0, const 
unsigned short * 0x002d56c8 gCommonEmptyBuffer) line 729
nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x03429040) line 
302

This is definitely not a show stopper, since we do load the page [ after 8 secs 
:-( ]...eventually. Marking FUTURE.

Note: This problem might go away when vidur lands the new parser changes( 
ofcourse not on the branch ). So, please bite the bullet for now.

Comment 4

[Andreas Franke (gone)]

Not sure if this qualifies for the "freeze" keyword, but adding it together with
"perf" to indicate a "freeze" that goes away after some time.

Comment 5

[Alec Flett]

ugh, seems to have gone away - dunno if the content changed, or gecko, but in
any case it's not reproducable anymore, and zing has been on f*ckedcompany.com
more than a few times lately :)