please retest with newer version. Close, or update comment/attach testcase as appropriate to test results. Thanks
Still happens exactly as described.
Timwi, does this happen with 3.6.9 in a fresh profile?
Yes, still happens exactly as described.
Reporter, Firefox 4.0.1 has been released, and it features significant improvements over previous releases. Can you please update to Firefox 4.0.1 or later, and retest your bug? Please also create a fresh profile ( http://support.mozilla.com/kb/Managing+profiles), update your plugins (Flash, Java, Quicktime, Reader, etc) and update your graphics driver and Operating system to the latest versions available. If you still continue to see this issue, please comment. If you do not, please close this bug as RESOLVED > WORKSFORME filter: prefirefox4uncobugs
This still occurs in Firefox 4.0.1 clean profile exactly as described. Perhaps it's time to CONFIRM this? It's the third time someone asks if it still happens.
This is _very_ hard to reproduce on fast (and even just non-slow) and reliable network connection. Some form of network decelerator or **** mobile internet connection recommended for testing. The other reason why Firefox can stay in this state for noticeable amount of time is because Firefox itself is slow (with multiple tabs or large images open or such).
Michal: No, it is very easy to reproduce on any connection speed. The PHP script in the bug description has a 2 second delay, and for me Firefox always reliably goes into the limbo state for those 2 seconds. If your connection is fast, you can just click the first link and then the second one without any waiting, and you’ll have reproduced it. It’ll navigate to mozilla.org, which it shouldn’t.
Sorry, did not notice the link since it's not in the URL field of the bug report. Crafting a web page that inserts artifical delays at unusual places is, of course, one way to make a "network decelerator".
Michael, I think it's entirely justified to offer a page that artificially simulates a network delay. In fact, wouldn't it be nice if all bug reports came with working repro cases? If the sites you visit happen to always complete their response within a couple hundred milliseconds, and your network connection never adds delays of its own then you're lucky, but this bug is still a problem for others. This issue occurs all the time whenever my ISP is overloaded on weekend nights.
Yes, would be even nicer if the test case was in the URL field of the bug. And I can easily (although not reliably) reproduce this or something similar on my system, even without the specially crafted web page. That's why I came here in the first place.
Firefox Nightly 7.0a1 (2011-06-21) Reproduces exactly as described, on all 3 counts.
Running 6.0.1 release -- can't reproduce.
Also running 6.0.1 - can reproduce each one of the three symptoms. Could you describe more accurately what you do, and what happens?
Just installed a completely fresh 6.0.1 with a new pristine profile. The bug reproduces just fine. Just click the first and then the second link. It happens every time.
With the current Firefox 7.0 beta (fresh profile), the bug is half-fixed. Clicking the link no longer follows its target as it did until 6.0.1. However, the old website and the new URL are still displayed at the same time (the "limbo state"); and the link becomes styled to appear as if it had been clicked, which is better than 6.0.1's behaviour, but still not very good user experience...
In Nightly 9.0a1 (2011-09-02), the second link can't be followed while the page is loading, and it doesn't become styled as "clicked" either. While I don't think this is anywhere close to "good" or "desirable", the limbo state is essentially unachievable now, at least using the linked repro case.