Christian :Biesinger (don't email me, ping me on IRC) Reporter
	Description • 20 years ago

from bug 157004 comment 83:
hm, I found a (small) problem with the patch, I think... with it, we load error
pages LOAD_BACKGROUND (note bug 157004 comment 52); but this means that we won't
fire
onStateChange (right?) - accessibility does want to get that, though...
(http://lxr.mozilla.org/seamonkey/source/accessible/src/base/nsDocAccessible.cpp#724,
http://lxr.mozilla.org/seamonkey/source/accessible/src/base/nsAccessibilityService.cpp#152)

	Darin Fisher
	Comment 1 • 20 years ago

Interesting.  So, how do we deal with OnLocationChange then?

	Darin Fisher
	Comment 2 • 20 years ago

One of the ideas I had a while back was to leverage onChannelRedirect to
implement error pages.  Combined with the "redirect is temporary" flag, we'd
have a decent solution (because the URL bar is not supposed to be updated when a
temporary redirect is followed).  It turns out that this would be even easier to
implement once we have nsBaseChannel :-)

That said, it seems we've already gone down the road somewhat of making docshell
smarter about handling error pages.  Not sure exactly where we want to go from here.

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 3 • 20 years ago

I'm not sure we want to implement errorpages on a channel level. Wouldn't that
cause stuff like images, stylesheets and document.load'ed documents to end up
with errorpage content?

	please CC darin dot moz at gmail dot com instead
	Comment 4 • 20 years ago

We could use a bit in the load flags field to enable error pages.  We already
have error pages coming from HTTP servers, so it seems consistent if necko were
to feed consumers error pages in other cases if they ask for them.  We could
likewise turn 404's into hard errors if desired by a consumer.