226401 - XUL (HTML) error pages should be stored in history or provide link to parent page

Status: VERIFIED DUPLICATE of bug 157004

(Firefox :: Bookmarks & History, enhancement)

Description

[rsr-web-bugzilla.mozilla.org]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031120 Firebird/0.7+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031120 Firebird/0.7+

Currently when an HTML error page is displayed, it replaces the parent page of
the erroring link in the window but does not appear in the session history.

This provides the user two ways to get back to the parent page: hit the back
button and then the forward button, or hit reload (which is not obvious as a
method until bug 157004 is resolved).  If the parent page was the first page in
the session history, the first method isn't available.

Once bug 157004 is fixed another method would be to highlight the location bar
and hit enter.  Another, possible, method would be for the error page to provide
an HTML link back to the parent page.

However, all of these latter solutions are technically flawed - they cause the
parent page to be unconditionally re-fetched.  This is especially troublesome if
the parent page had some side-effect (e.g. it was the results page of sending an
e-mail message or posting a comment to a weblog).

The easiest solution is for the HTML error page to appear in the session
history.  It is obviously a web page (witness bug 157004), and I personally
think it is the most intuitive behavior.  The only argument against I can see is
that it destroys the session's forward history; however the user was expecting
this anyhow as soon as they clicked on the error-generating link.

The only other correct solution is for there to be a link to the parent page
which does NOT cause a re-fetch.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Bob Firth]

this looks like an enhancement to me.changing summary accordingly.

for the record, the summary was: "XUL (HTML) error pages provide no clean method
of returning to the parent page" in case something thinks I'm stupid and wants
to change it back.

Comment 2

[Augusto Daniele]

i think this sholud be a bug more than a enhancement 

still happening on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b)
Gecko/20040314 Firefox/0.8.0+ (BlueFyre)

Comment 3

[Doug Halamay]

This looks to be related to bug 157004.

Comment 4

[Jesse Ruderman]

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

Comment 5

[Jesse Ruderman]

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

Comment 6

[Bill Mason]

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

Comment 7

[Bill Mason]

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

Comment 8

[Bill Mason]

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

Comment 9

[Matthias Versen [:Matti]]

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

Comment 10

[Jesse Ruderman]

This was fixed in bug 157004, right?

Comment 11

[Edward Z. Yang]

As an extra note, if you do not have a history of page views for your screen,
the back button is totally disabled, so you *cannot* return to the parent page
via the fix suggested, that is, pressing back, and then pressing forward.

Having the History bar on results in more confusing behavior: if you type in an
invalid URL that would cause the XUL page to be called, that immediately shows
up in your History. Valid pages, however, *do not* automatically show up,
instead, you must close the history sidebar and reopen it. Conversly, all error
pages disappear from the History bar once it has been closed and reopened.

This behavior appears to be the same for the Go bar, except that you must open a
new instance of Firefox to purge the cache.

What causes this problem? Buggy implementation of XUL pages: error handling was
not configured this way. This should be a feature request, but the quick hack
that emulates the feature causes lots of bugs. This is, in my opinion, something
that needs to be implemented fast.

Comment 12

[Jesse Ruderman]

*** This bug has been marked as a duplicate of 157004 ***

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+1]]

v.