Closed
Bug 36285
Opened 25 years ago
Closed 24 years ago
Lengthy lockup while loading url
Categories
(Core :: Layout, defect, P3)
Tracking
()
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.
Reporter | ||
Comment 1•25 years ago
|
||
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 :)
Reporter | ||
Comment 3•25 years ago
|
||
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.
Reporter | ||
Comment 7•25 years ago
|
||
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.
Comment 9•24 years ago
|
||
richard@iopen.co.nz - can this bug be closed now?
Gerv
Reporter | ||
Comment 10•24 years ago
|
||
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.
Comment 11•24 years ago
|
||
*** This bug has been marked as a duplicate of 21637 ***
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•