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
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
You need to log in before you can comment on or make changes to this bug.