Tab / Browser deadlock while loading page into new tab.



15 years ago
13 years ago


(Reporter: tswain, Unassigned)


Windows 98

Firefox Tracking Flags

(Not tracked)




15 years ago
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
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.

Comment 1

15 years ago
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? 
Product: Browser → Seamonkey

Comment 2

14 years ago
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:
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.
Last Resolved: 13 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.