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
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
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?
Created attachment 274412 [details] jprof profile 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.
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.
Do you have GNOME accessibility enabled? I'd be curious if it hang with it disabled.
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 389873
You need to log in before you can comment on or make changes to this bug.