Open Bug 223808 Opened 21 years ago Updated 2 years ago

Reload button does not work after timeout

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Type:
defect

Tracking

()

People

(Reporter: david.balazic, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624

I opened the URL above by middle clicking on a link. I have the "middle button
opens in new tab" & "load links in the background" options enabled. I also
middle clicked another similar link. Both timed out ( a dialog appeared for both
), because the network had some temporarily problems. After a minute the network
recovered. I tried to reload the problematic tabs by clicking the reload button.
Nothing happened. The page remaimed empty, the tab stayed "(Untitled)" , the
window title "Mozilla". The URL box has the correct URL. I tried the reload
button several times, no response. Then I clicked in the URL box, typed ENTER
and then it (re)loaded.

Same problem with the second tab. RELOAD -> no response, also tried SHIFT-RELOAD
and CTRL-RELOAD. I clicked GO and then the page loads.

One can argue that nothing was loaded so there is nothing to reload, but it is
not intuitive. The URL was already entered and once it was tried to be loaded,
so it is "logical" to the user, that he retries by clicking RELOAD.

Reproducible: Didn't try

Steps to Reproduce:
I forgot to mention: when positioned on one of the failed tabs, ctrl-t does not
open a new tab. If select a "normal" tab, ctrl-t opens a new empty tab. If I
close it and select again the "bad" tab, ctrl-t does not work again.
sending this over to tab browser land.  maybe it is doing something odd to cause
this behavior.  interesting that RELOAD and ENTER typed in url bar would not
load the same URL.

reporter: am i correct in assuming that this problem only occurs when using
multiple tabs?

-> tabbrowser
Assignee: darin → tabbed-browser
Component: Networking: HTTP → Tabbed Browser
"reload" uses the "current URI" of the docshell.  If the request times out, the
current uri of the docshell does not change (since there is never an
OnStartRequest)....
bz: necko should produce OnStartRequest coupled with OnStopRequest with every
request... whether the request fails or succeeds.  timeout or otherwise.  are
you sure OnStartRequest is not being called?
Hmm.. Actually, OnStopRequest _is_ called, but the attempt to get the HTTP
response status in nsDocumentOpenInfo::OnStartRequest fails (nsHttpChannel
throws) and hence the URILoader never propagates that notification back to the
docshell.

In a way, that makes some sense -- the current URI of the docshell should not be
changing if the actual page being shown did not change...
ok, but then at least the URL loaded when the user presses ENTER should not
differ from the URL loaded when the user presses RELOAD.
Darin, if I focus the URL bar and type a bit and hit enter, I get a different
page loading than if I focus and type and hit reload....

I suppose we could try to change the semantics of "reload" to mean "repeat the
last load that either completed successfully in this docshell or did not
complete successfully"....  I'm not quite sure who (apart from radha) knows that
code, though...
should I open a separate bug for ctrl-t not working ?
If one does not exist (doubtful), then yes.  Keyboard nav component.
I opened bug 224036 for the ctrl-t issue.

The reload issue is also happening in :
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4.1) Gecko/20031008
So the point is that the browser's "reload" UI needs to only use the docshell's
URL if the last time it tried to start a load that load "worked" (it at least
got some progress reports).  Otherwise it just needs to call loadURI() with the
last URI it tried...

You can reproduce this issue even without a network timeout -- type in a URL
that will get handled in a helper, then hit reload.  The current page will
reaload, instead of realoading the request that got handled by a helper.
Note that I would be OK with pushing the logic I described in comment 11 down
into docshell itself (which implements the webnavigation reload() method) if we
are sure that _all_ embeddors want that behavior.  Or we could add a flag to
reload() that allows controlling the behavior.  Or we could leave it entirely up
to the embeddor to decide, per my original suggestion.  CCing some embedding
types to comment on the issues.
hrm, will this only affect the *first* URI loaded in the docshell? If I already
have a page loaded, I expect the "reload" button to reload that, not whatever is
in the URL bar.

My suggestion, if it's not too hard, would be to set the docshell URI to the
first page it tries to load, even if that fails.
Doing that is likely to cause all sorts of session history problems...

The idea I was suggesting is that the URI of a "failed load" would be stored
somewhere either by docshell or the embeddor.  It would be reset on a
"successful load".  "reloat" would try the "failed load" URI if it exists; the
docshell URI otherwise.
This also happens with URLs that gave a 'Connection Refused' dialog, although
CTRL+T still opens a new tab.  Maybe I should file a new bug?

Couldn't find a URL that would time out (rather than refuse the connection) to
test the reported issue.
No need for a new bug -- that's this bug.
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:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Well, error pages work around most of these issues these days...
Not a tabbed browser issue; this is a docshell api question. See comment 12. 
Note that if we're going to freeze nsIWebNavigation we should sort this out first.
Assignee: tabbed-browser → adamlock
Blocks: 99625
Status: UNCONFIRMED → NEW
Component: Tabbed Browser → Embedding: Docshell
Ever confirmed: true
OS: Windows 2000 → All
QA Contact: networking.http → adamlock
Hardware: PC → All
Assignee: adamlock → nobody
QA Contact: adamlock → docshell
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.