Browser stops responding for extended period

VERIFIED FIXED

Status

()

Core
Layout
P3
normal
VERIFIED FIXED
19 years ago
18 years ago

People

(Reporter: r.navalinskas, Assigned: vidur (gone))

Tracking

({perf})

Trunk
x86
Windows 98
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

19 years ago
I found this problem yesterday, and it also exists in today's nightly build. I 
tried to check bug http://bugzilla.mozilla.org/show_bug.cgi?id=26796 ,
but browser at the http://www.sports.ru went even futher - stop responding, and 
even all other programs could not get focus. There were no response to mouse 
clicks not only in mozilla programs, but there was no response to _any_ mouse 
clicks. Well, that wasn't total OS crash, since Ctrl+Alt+Del and EndTasking 
Mozilla brought everything to normal conditions.

Comment 1

19 years ago
Confirmed with the 2000-02-22-08-M14 nightly binary on Windows NT;
64MB memory, P120, modem connection.

It would be easy for a user to come to the conclusion that Mozilla had hung,
but what is happening here is no more than the ordinary (for complex pages) 
grind just before the [Stop] button greys, much worse than usual. The page has 
many fast animated gifs.

The non-responsiveness is due to tens of seconds of 90%+ CPU usage, but during
this period both Mozilla and other Apps did respond, albeit with delays of
many seconds and very slowly. After the page loads, responsiveness returns to
normal. It's very unlikely that most users with older, slower machines would 
wait that long, however.

This could very well be the same issue as in bug 26028, "extremely long delay 
after loading page". I've seen the same problem loading a local copy of the
MySQL manual (~1MB of straight clean HTML)
Assignee: cbegle → troy
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout
Ever confirmed: true
Keywords: perf
QA Contact: asadotzler → petersen
Summary: Browser stops responding → Browser stops responding for extended period

Comment 2

19 years ago
Vidur, here's what I know about this:
- the huge delay is because of hundreds of thousands of calls to DrawImage() 
from the CSS rendering PaintBackground() code. Quantify verified this and said 
it was associated with a table cell frame that has a background (presumably)
- it's somehow associated with the JavaScript code in the page. I know this 
because I made a local copy, removed the SCRIPT tags and then it loads quickly. 
Add back in the SCRIPT tags and it gets really slow

I'm guessing that what happens is that the script does something like set the 
background image and that causes style to repaint it. Why we do it so many 
times, though, I don't know

I'm hoping you have some insight into what's going on in the script stuff
Assignee: troy → vidur

Comment 3

19 years ago
Wondering if this could have any similarities to bug 18189, "[INC CONTENT SINK] 
select scrollbars display multiple times", M15.

Retested with the 2000-02-28-08 binary on WinNT on a faster machine, the 
processor bog seemed to coincide with the final reflow of the page. On 
reload, with the files coming out of the cache and presumably being parsed
before the first incremental reflow could happen, there was no problem
with responsiveness at all.

Comment 4

19 years ago
Tested with Build 2000-05-05-13 on a Pentium II 350 MHz running on Windows 98 SE
and couldn't reproduce the problem. Is my machine too fast, or has the problem
been fixed?
(Assignee)

Comment 5

18 years ago
Seems like the performace problem has been fixed. There is a crash on the 6/15 
build. Investigating...
(Assignee)

Comment 6

18 years ago
No crash, actually. Marking the bug FIXED.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 7

18 years ago
Fixed in the July 14th builds.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.