440785 - During page loading, a limbo state exists during which clicking links causes unexpected behaviour

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[Timwi]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.9) Gecko/2008052906 Firefox/3.0

When a web server starts responding with part of the contents of the response, Firefox/Mozilla/Gecko goes into a limbo state in which unexpected behaviour (described below) occurs while another webpage is still displayed.

Let's call the initial website X, and the website that has partially responded, we'll call Y.

The duration of the limbo state is variable. Usually it is very short because a substantial part of the new content is transmitted quickly and rendering begins immediately. Sometimes it is long, either because the server actually responds slowly, or because Firefox/Mozilla/Gecko is waiting to retrieve additional items such as JS or CSS. But either way, it's because rendering is delayed.

There are several unexpected behaviours arising during the limbo state:

1) The location bar displays the URL of Y, when in fact the page X is
   still displayed.

2) The URL of webpage Y is added to the history, despite the fact that X
   is still displayed. So from the point of view of the user, we never
   left X. If you then click on a link on X that leads to a webpage Z,
   then wait for that to load, then press Back,
   EXPECTED BEHAVIOUR: you should be sent back to X.
   ACTUAL BEHAVIOUR: you are sent to Y.

3) Links on the still-displayed webpage X lose their JavaScript. If you
   have an <a> tag whose onclick event outputs an alert and returns
   false,
   EXPECTED BEHAVIOUR: alert pops up and nothing else happens.
   ACTUAL BEHAVIOUR: the URL in the href is followed as if the
   JavaScript didn't exist.


This should be quite easy to fix. At the point where the server responds with part of the content, even if you're not going to render any of it, start the rendering process anyway (causing a blank white page, waiting for more content).

If you were to insist that page X should continue to be displayed for as long as absolutely possible, then a proper fix should delay everything to do with switching pages until we have something to render. That includes adding the URL to the history, changing the contents of the Location bar, and whatever it is that disables the JavaScript. The limbo state, and associated strange behaviour, happens because rendering starts later than all these other actions.

Reproducible: Always

Steps to Reproduce:
0. Make sure that you have JavaScript enabled.
1. Visit http://www.csrsupport.com/bug_show_case.php
2. Click the first link, labeled "Click this first".

EXPECTED BEHAVIOUR: URL in the Location bar should not change any earlier than the current webpage (bug_show_case.php) disappears.
ACTUAL BEHAVIOUR: URL changes at least 2 seconds earlier (there is a 2-second sleep in the PHP script).

3. Wait for the URL in the Location bar to change, but don't wait too long so
   that the webpage appears.
4. Click the second link, labeled "Then click this link".

EXPECTED BEHAVIOUR: JavaScript alert pops up.
ACTUAL BEHAVIOUR: Browser navigates to http://www.mozilla.org/

5. Click "Back" or press Alt+Left.

EXPECTED BEHAVIOUR: Browser goes back to bug_show_case.php
ACTUAL BEHAVIOUR: Browser reattempts to load long_response.php

Comment 1

[Wayne Mery (:wsmwk)]

please retest with newer version.  Close, or update comment/attach testcase as appropriate to test results. Thanks

Comment 2

[Timwi]

Still happens exactly as described.

Comment 3

[Tyler Downer [He/Him]]

Timwi, does this happen with 3.6.9 in a fresh profile?

Comment 4

[Timwi]

Yes, still happens exactly as described.

Comment 5

[Tyler Downer [He/Him]]

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

Comment 6

[Roman]

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.

Comment 7

[Michal 'hramrach' Suchanek]

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).

Comment 8

[Timwi]

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.

Comment 9

[Michal 'hramrach' Suchanek]

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".

Comment 10

[Roman]

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.

Comment 11

[Michal 'hramrach' Suchanek]

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.

Comment 12

[Roman]

Firefox Nightly 7.0a1 (2011-06-21)

Reproduces exactly as described, on all 3 counts.

Comment 13

[George Nassar]

Running 6.0.1 release -- can't reproduce.

Comment 14

[Roman]

Also running 6.0.1 - can reproduce each one of the three symptoms. Could you describe more accurately what you do, and what happens?

Comment 15

[Timwi]

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.

Comment 16

[Timwi]

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...

Comment 17

[Roman]

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.