300863 - No history created for "unknown protocol" error page

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect, P1)

Description

[Ng Ming Hong]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+

URL history is not created for XUL error pages, making it impossible to go back
to the previous page when the link followed has error.

Reproducible: Always

Steps to Reproduce:
1. Visit the URL provided in a new tab (to avoid the previous history that may
confuse you)
2. Click on one of the links
3. Look at the toolbar

Actual Results:  
Backward button is grayed out.

Expected Results:  
Allow me to go backward since I didn't have klik installed.

Workaround: reload the error page. It will bring you back to the "previous page".

Comment 1

[Ben Basson]

Confirmed, but this happens without the bfcache too, so this doesn't block bug
274784.

Nominating 1.8b4 since XUL error pages are now enabled by default and the
changes required will probably need testing. 

Nominating 1.1 because this will be a fairly visible bug.

Comment 2

[Ria Klaassen (not reading all bugmail)]

My history is full of "Page Load Error"'s including the addresses. 
When I load a series of existing and non-existing pages I can navigate through
them back and forward. The existing pages are pulled from the cache but the
non-existing pages are requested once more.
So I assume I misunderstand the bug.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050714
Firefox/1.0+ ID:2005071422

Comment 3

[Ria Klaassen (not reading all bugmail)]

Well, I tried the same again with the very latest build and a shining new
profile, but exactly the same result.
When I reload the error page it reloads the address that caused the error page.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050715
Firefox/1.0+ ID:2005071501

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

hm... seems to only happen with "unknown protocol"?

Comment 5

[Ng Ming Hong]

Christian, you're right. Changed the summary.

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

urg, I forgot that only newURI worked for unknown protocols, not newChannel...

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch v0.5

this almost works, except that the urlbar is wrong in some cases

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 189617 [details] [diff] [review]
patch v0.5

ok, the urlbar issue will need a frontend patch, requesting review on this one
in the meantime

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: xpfe patch

OK, I think this is correct. If a user selects something from the dropdown, we
should use that as value, and not overwrite it with the part that the user
typed (nsBrowserStatusHandler would overwrite it with what they typed). this is
an issue because there is no onStateChange for this case.

Comment 10

[Boris Zbarsky [:bzbarsky]]

So this fires onLocationChange and such without a channel?  Isn't that a
violation of the nsIWebProgressListener API?  Do we need to just synthesize a
channel here?

Comment 11

[Christian :Biesinger (don't email me, ping me on IRC)]

http://lxr.mozilla.org/seamonkey/source/uriloader/base/nsIWebProgressListener.idl#305
sounds like this won't be a violation...

and there is no "and such", only onLocationChange is fired.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 189617 [details] [diff] [review]
patch v0.5

Ah, ok.  If all we fire is OnLocationChange, then this is fine.

Comment 13

[Darin Fisher]

Comment on attachment 189617 [details] [diff] [review]
patch v0.5

I think we should rename OnLoadingSite to OnNewChannel ;-)

sr=darin

Comment 14

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 189617 [details] [diff] [review]
patch v0.5

makes error pages behave a lot better with shistory in the case of unknown
protocol errors.

Comment 15

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 190251 [details] [diff] [review]
xpfe patch

this patch is actually pointless given bug 286811

Comment 16

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: merged to trunk

Comment 17

[Christian :Biesinger (don't email me, ping me on IRC)]

Checking in docshell/base/nsDocShell.cpp;
/cvsroot/mozilla/docshell/base/nsDocShell.cpp,v  <--  nsDocShell.cpp
new revision: 1.706; previous revision: 1.705
done