Closed
Bug 390033
Opened 17 years ago
Closed 17 years ago
Looking at Mozilla source file in LXR freezes browser almost completely
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 389873
People
(Reporter: dennisml, Unassigned)
References
()
Details
(Keywords: hang)
Attachments
(1 file)
71.79 KB,
application/x-gzip
|
Details |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a7pre) Gecko/2007072904 Minefield/3.0a7pre Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a7pre) Gecko/2007072904 Minefield/3.0a7pre When opening the provided URL in recent Firefox builds the browser freezes for a long time but not completely. For the first few seconds everything seems to be ok but then Firefox locks up almost completely which means you can click on the stop button and then have to wait for a minute for Firefox to respond. Reproducible: Always Steps to Reproduce: 1. Go to provided URL Actual Results: Firefox locks up almost completely Expected Results: Firefox should stay responsive
Reporter | ||
Updated•17 years ago
|
Version: unspecified → Trunk
Comment 1•17 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a7pre) Gecko/2007072904 Minefield/3.0a7pre ID:2007072904 WFM. Do you see the same thing if you make a new firefox profile? http://kb.mozillazine.org/Profile_manager
Reporter | ||
Comment 2•17 years ago
|
||
Yes, I also tried running FF in safe-mode but I get the same result. Sysprof says that 98% of the time is spent somewhere in libxul.so. What would be the proper way to find out where exactly in libxul.so this time is spent?
Reporter | ||
Comment 3•17 years ago
|
||
I went ahead and created a jprof enabled debug build and used the following profiling options: JP_START JP_FIRST=3 JP_PERIOD=0.025 The profile covers only the loading of the page i.e. I started loading the page just when jprof received the first signal, then waited 3-4 minutes, then hit the stop button and when FF responded after another 1-2 minutes I immediately quit Firefox.
Reporter | ||
Comment 4•17 years ago
|
||
One final observation for today: Grabbing the URL with wget and loading it locally shows the page instantaneously so this problem only show up when I get the file over the network.
Comment 5•17 years ago
|
||
Do you have GNOME accessibility enabled? I'd be curious if it hang with it disabled.
Reporter | ||
Comment 6•17 years ago
|
||
Surprisingly enough it was and after disabling it the problem disappeared. This fixes the bug for me since I don't need the accessibility features in the first place but it might still be a problem for people who do.
Updated•17 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•