It looks a lot like the developertutorials.com site using a javascript from http://kona.kontera.com which is an "advertising" site. I haven't traced through all the javascript file loads that result from the use of KonaLibInLine.js but it looks like they are setting up timeouts in the initial file (e.g. dc_ALTimeout=900).
PLEASE! - ALL FUTURE ADDITIONS TO THIS BUG SHOULD INDICATE WHETHER JAVASCRIPT IS ENABLED OR BLOCKED. Esp. with respect to "unknown" sites. Tracing javascript timeout calls is very difficult if they go through several levels of indirection to get to the code which is setting and springing the timeouts.
HTTP Refresh problems causing destroyed+detached windows are probably much easier to trace than complex javascript timeout window manipulations.
It should be noted that this is *not* a case of Firefox getting "worse" (the problem has been around for ages), the problem is that the advertisers are making more frequent use of AJAX/Web 3.0/Timeouts in attempts to shove different ads down your throat -- "Well they didn't click on that ad after 5 minutes -- lets throw a different ad at them.".
If you are using "unsafe" sites with Javascript enabled (NoScript solves many of these problems) then (cough) you get what you deserve. You *are* allowing commercial enterprises (and corrupted web sites) to run programs (not merely display text) on your computer. Of course one should only worry about browser security, after say what -- half a million bugs? A browser with less than that, say 383,866 bugs, well certainly that's got to be a "safe" system.
It looks a lot like the developertutori als.com site using a javascript from http:// kona.kontera. com which is an "advertising" site. I haven't traced through all the javascript file loads that result from the use of KonaLibInLine.js but it looks like they are setting up timeouts in the initial file (e.g. dc_ALTimeout=900).
PLEASE! - ALL FUTURE ADDITIONS TO THIS BUG SHOULD INDICATE WHETHER JAVASCRIPT IS ENABLED OR BLOCKED. Esp. with respect to "unknown" sites. Tracing javascript timeout calls is very difficult if they go through several levels of indirection to get to the code which is setting and springing the timeouts.
HTTP Refresh problems causing destroyed+detached windows are probably much easier to trace than complex javascript timeout window manipulations.
It should be noted that this is *not* a case of Firefox getting "worse" (the problem has been around for ages), the problem is that the advertisers are making more frequent use of AJAX/Web 3.0/Timeouts in attempts to shove different ads down your throat -- "Well they didn't click on that ad after 5 minutes -- lets throw a different ad at them.".
If you are using "unsafe" sites with Javascript enabled (NoScript solves many of these problems) then (cough) you get what you deserve. You *are* allowing commercial enterprises (and corrupted web sites) to run programs (not merely display text) on your computer. Of course one should only worry about browser security, after say what -- half a million bugs? A browser with less than that, say 383,866 bugs, well certainly that's got to be a "safe" system.