User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 Mozilla 1.5 Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 Browser and tabs deadlock while loading page. Something is hogging the CPU when loading a page. Preempt the offending Thread 20MS per iteration. Sad to have to do but at the bottom of the equation Windows sheduling sucks and you can't rely on it to preempt itself. Reproducible: Always Steps to Reproduce: 1. Load page http://hyperbyte.ab.ca/hyperview/HyperView.html 2. Load one or more links in the left side table into a new tab. 3. Try switching tabs. The Browser is deadlocked till the page arrives. If the page deson't arrive the Browser is deadlocked till it times out. Actual Results: Deadlocked Browser Expected Results: Preempt the Thread periodically allow the other tabs some CPU times. According to the "Exec Constant" 20 millseconds per iteration. Tony's Law of the Exec Constant. In an operating system where threads or tasks are allowed to hog the CPU, Not mentioning any names like M$ A thread SHOULD preempt itself for at least 20 millseconds per iteration. This holds true in every OS I have tested from 7Mhz upwards :) This amount of time is not noticable on performance, and allows cycles to be spared for other things. Usually the Browser recovers but it is really unporductive to have it locked up as such because you can't do anything while it is in this state. Moreover if there is a lag or the page is unavailable it can be locked up for an annoyingly long time.
reporter: mozilla does all dom and layout work for all tabs and windows on a single thread (the main thread). while it might be nice to do things differently, it will require work. are you volunteering to help change this?
I can understand your comment about this being a lot of work, but certainly under FireFox this effectively kills the browser. I have had "Firefox is not responding would you like to kill it" messages from windows. This looks very bad on FF and really makes it a pig to use. Take this example, your reading slashdot and the reg, you load up a really slow page in a new tab. Bang it's all completely unuseable. I would offer to help, but I know nothing about threading in C and so that's not a lot of help. Java sure, but I'm guessing FF isn't writtne in that :p
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.