Closed Bug 36285 Opened 24 years ago Closed 24 years ago

Lengthy lockup while loading url

Categories

(Core :: Layout, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED DUPLICATE of bug 21637

People

(Reporter: richard, Assigned: waqar)

References

()

Details

Tested with -

M15 release - Build ID 2000041805, and
Daily build - Build ID 2000041718.

While loading the above url (or any search returning a reasonable number of
results from the same site), mozilla uses 95% of cpu and disallows interaction
for an extended period of time.
On further browsing this bug seems to occur on practically any page of large

length, including the bugzilla unconfirmed bugs page.  Also seems to have a

lasting effect on the performance of the browser if any attempt to scroll up and

down the loaded page is made.



This bug seems to be a recurring duplicate bug from a while back (pre. m14 at

least).



Changing to major for now.

Severity: normal → major
I can confirm this (linuxppc 2000041919) (the lockup anyway, I don't seem to be
experiencing any performance effect after scrolling up and down several times).
richard@iopen.co.nz what bug(s) do you think this is a dupe of? oh and by the
way you shouldn't have to cc yourself on your own bugs :)
Ok - I've had a quick skim through the bugs and this seems to duplicate at least
-

1631 - fixed
25509 - fixed
21637 - open

Changing to component from browser-general to layout.

b.judd@xtra.co.nz - can you confirm that this is a duplicate of 21637?

A little more on the performance problem I was referring to - when I load a
large page, and scroll up and down a number of times, then perform a similar
action in a new window, all windows seem to take a substantial performance hit
even after I have closed the original windows - the interface becomes
unresponsive.
Component: Browser-General → Layout
Well I will allow that it looks quite similar to 21637 but I don't have enough
experience to say if it is the same bug. They don't mention the performance
hit...mind you the performance bug and the delay may be two different bugs
altogether. If you made a new bug for just the performance hit and then marked
this one as a duplicate of 21637 that would be okay. In any case I still don't
see the performance hit despite your improved instructions. Just to be sure, can
you give me a detailed step by step set of instructions (1 do this 2 do that 3
do such and such etc.) of what exactly you do to get this?
Oh and in case that was what you were asking, no my privs don't allow me to set
this as a dupe of 21637.
reassign
Assignee: asadotzler → troy
QA Contact: jelwell → petersen
Using build 2000042609 on linux	x86 I can no longer duplicate the performance
problems so it seems to have gone away for now - at least in that particular
manifestation.  I'll check it over the next few builds to see what happens.  The
original bug seems to have improved a little in this build as well with shorter
periods of 'freezing' than I was experiencing before.
Reassigning to waqar - Triaging Troy's bug list.
Assignee: troy → waqar
richard@iopen.co.nz - can this bug be closed now?

Gerv
BuildID: 2000051820

I'm still seeing short periods of 'lockup' where neither the progress bar nor
the throbber show any activity.  Seems to be better than before, but I haven't
tested against really long pages.  It (naively) seems to be a problem not so
much with the actual rendering or download, but with the interface not being
updated during those periods.

gervase.markham@univ.ox.ac.uk - this bug may well be a duplicate of the bugs
mentioned above, and if so, it could be marked duplicate and closed.

*** This bug has been marked as a duplicate of 21637 ***
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Verified duplicate.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.