215753 - Try Again link on error pages points to chrome.

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect)

Description

[Jason Bassford]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030810
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030810

This is an offshoot from bug 214949.  Even though the full error messages have
been restored, the Try Again link points not to the attempted URL but to the
chrome error message.  This renders the link useless.

Reproducible: Always

Steps to Reproduce:
1. Disconnect your computer from the Internet.
2. Try to go to a Web site.


Actual Results:  
You'll get the full error message, but the Try Again link will only go to the
chrome error, not the intended URL.

Expected Results:  
Try Again should go to the intended URL.  (As does the location bar now.)

Comment 1

[Jason Bassford]

CCing Christopher who worked on bug 214949.

Comment 2

[Christopher Aillon (sabbatical, not receiving bugmail)]

As far as I can tell, this was always the behavior.  See bug 214949 comment 6.

Comment 3

[Jason Bassford]

That comment was my own. <grin>

Up until about two weeks ago, the location bar showed the chrome, while Try
Again linked to the intended URL.

Then, around that time, the two "swapped" so that the location bar showed the
intended URL while Try Again showed the chrome.  At the same time, the long
error message disappeared and *only* Try Again was shown.

The resolution of bug 214949 brought back the long error message, but still
hasn't fixed the Try Again link.

(My bug 214949 comment 6 note was about the fact that in fixing the regression,
I wanted to make sure that the location bar entry *remained* the intended URL -
which is something that's been desired for a while now.)

Comment 4

[Christopher Aillon (sabbatical, not receiving bugmail)]

Also, this has nothing to do with security.

Comment 5

[Jeremy Lin]

(I'm not sure if the following is just another facet of this bug, so let me know
if a new entry is appropriate.) If I'm on a modem connection and downloading
something while trying to load pages, at some point I'll inevitably get
something like this:

In the location bar:
chrome://global/content/netError.xhtml?e=netReset&u=http%3A//www.wired.com/news/nc_index.html&d=The%20document%20contains%20no%20data.
In the 
chrome://global/content/netError.xhtml?e=netReset&u=http%3A//www.wired.com/news/nc_index.html&d=The%20document%20contains%20no%20data.#

Effectively, this means there is no way to try again, short of copying and
pasting the URL out of the error message and replacing the 'http%3A' part with
'http:'. This is annoying, and didn't happen pre-1.4 as far as I remember.

Comment 6

[Jason Bassford]

Actually, interestingly enough, despite the fact that the "Try Again" link shows
the chrome, rather than the failed URL, clicking on it still takes you to where
you want to go.  Which is even more bizarre than I'd thought at first when I
filed this - since it should be showing and doing the same thing...

Comment 7

[mmortal03]

Something has changed recently, and now, the link ISN'T taking you to the page
anyway.  After clicking it, the chrome url loads in the address bar.  THEN when
clicking Try Again does it try reloading the page.

Comment 8

[Jason Bassford]

I think that the fix for bug 214949 also introduced something else that wasn't
there before.  If you drag and drop a piece of text containing a URL to the tab
bar (so that it's opened in a new tab) and the URL is invalid, we now get the
Try Again page in both the new tab *and* in the original tab (the original tab
shouldn't be touched).  I'm going to file a new bug on this tonight when I have
a chance to reproduce the problem with a current build.

Comment 9

[Jason Bassford]

Forget about comment 8.  I can't reproduce it in the latest build. <grin>

Comment 10

[Mike Calmus]

It appears te fix for bug #237244 has fixed this bug as well. Can it be marked
as fixed?

Comment 11

[Jason Bassford]

This bug fixed by the fix for bug 237244.

If the problem mentioned in comment 5 persists in any way (I notice a new try
again button now, rather than just a link, and, so far, I haven't been able to
reproduce the "#" problem in a 2/28 build) then that should be filed as a
separate bug.