95897 - the first URL in a new window isn't added to session history until it starts loading

Status: RESOLVED WONTFIX

(Core :: DOM: Navigation, defect)

Description

[Niels Aufbau]

Steps to reproduce:

1. Middle-click on a black-hole link, such as http://1.1.1.1/, or a link within
http://slashdot.org/ on some nights.  (http://slashdot.org/ itself seems to
always work, but URLs within the site often time out.)
2. Click reload (in the new window).
Result: nothing happens (bad).

3. Click stop.
Result: stops loading the page (good).

4. Click reload.
Result: reload still does nothing (bad).

5. Hit the home button or select a bookmark.
Result: the back button does not light up (really bad: if you closed your other
slashdot windows, you've just lost your place in the discussion).


I assume that 4 and 5 both happen because the URL isn't in session history.  If
that's not the case, feel free to split this bug into smaller pieces.

Comment 1

[Ariel Gonzalez]

Confirm with build 2001-08-17-03 under Win2k
If you open a new window and that URL times out, you cannot reload. If you
reselect the url in the bar and hit ENTER, then it retrys.

Comment 2

[Christopher Aillon (sabbatical, not receiving bugmail)]

Confirming.  Fixing this bug would probably fix bug 77641.

Comment 3

[Radha on family leave (not reading bugmail)]

Pages are added to session history as soon as a successful connection is made to
the site by necko  ie., onStartDocumentLoad() on the page is called.  If this
does not happen on a site, (for what ever reason, bad url or timeout etc...) it
will not be added to session history. The user may not see the effect on the
screen until something shows up. However it is added as soon as a
onStartDocumentLoad() is called on the site. This is a feature. Reversing it,
gives rise to lots of issues that makes the browser's history behavior
unpredictable.  

Comment 4

[Niels Aufbau]

*** Bug 103784 has been marked as a duplicate of this bug. ***

Comment 5

[Joe Hewitt (gone)]

*** Bug 120591 has been marked as a duplicate of this bug. ***

Comment 6

[dylang]

Isn't there some way we could change how the reload button / ctrl+r works such
that it's the same as hitting enter in the URL area?  It shouldn't need to touch
history, as noted, until it loads correctly.  But that doesn't mean reload
shouldn't work.

Comment 7

[Jonas Jørgensen]

I filed bug 125772 about disabling the Reload button until the URL starts
loading. (Better it's disabled than having people lose their URLs by clicking it...)

Comment 8

[Jesse Ruderman]

See also bug 97641, "reload does nothing after moz fails to connect to home page
(or first page in a window)".

Comment 9

[Jonas Jørgensen]

I'm not sure what should be done about this. We have two options:

1) Fix bug 125772 -- disable the Reload button until the URL is added to session
history. That will fix the dataloss aspect of this bug.

2) Implement what Dylan_G suggested in comment 6 -- do a special hack for making
Reload act as the Go button if there are no URLs in session history.

1 is what IE does, 2 is what Opera does. Personally I am in favor of 1.

Mpt, what do you think?

Comment 10

[[e-mail]]

I would strongly suggest to mark bug 125772 as WONTFIX and fix this 
in some way similar to what is suggested in comment #6. 
Please look at that from the point of view of a user trying to reach a page:
if it takes too long, he/she will try again using the reload button, disabling
the reload button would be frustrating.
If the connection fails, he/she will also try again, clearing the URL
or still having a disabled button in that situation is just silly.

Please help to make mozilla a non-frustrating experience for users: maybe
you should actually try and see what you expect of the browser when you
want to reach a slow site. I am sure having the browser deny you pressing the
reload button is not it.

Comment 11

[[e-mail]]

Could someone please reopen this bug? It is definitely a bug since 
mozilla shows a completely unexpected and illogical behaviour. 
And I think the decision never to solve this bug is way too premature,
so please reopen. Moreover it will help people who report this to find
the bug and avoid duplicates.

Comment 12

[Radha on family leave (not reading bugmail)]

It is not appropriate to implement the suggestion made in comment #6. Reload
button is similar to the Refresh button in IE and is closely tied to cache. 
Reload button's  behavior is more dependant on cache and its policies than
history. Making reload button behave like 'pressing enter on urlbar' will break
a ton of things especially in secure sites, postdata results, pages with
'no-cache, no-store' directives. Fixing bug 125772 sounds more appropriate.

Comment 13

[Jonas Jørgensen]

Johann: Even if we decide to implement the suggestion made in comment #6, this
bug should remain WONTFIXed. Rather, we should reopen either bug 103784 or bug
120591.

Radha: I believe he meant that the Reload button should only act as pressing
Enter in the URL bar _if no URL has been added to session history yet_, i.e., in
the cases where the Reload button would be disabled if bug 125772 was
implemented. In other words, some sort of hack which detects whether session
history is empty, and, if so, acts as if we've just pressed Go rather than
Reload. Would this be okay with you? Reload button behavior in all other cases
would of course remain the same as it is now.

> Reload button is similar to the Refresh button in IE

Funny you should mention it, since Internet Explorer's behavior is in fact in
the way comment #6 suggests. :-)