Open Bug 285055 Opened 17 years ago Updated 10 years ago

consider loading error pages without LOAD_BACKGROUND

Categories

(Core :: DOM: Navigation, defect)

x86
Linux
defect
Not set
normal

Tracking

()

People

(Reporter: Biesinger, Unassigned)

References

Details

(Keywords: helpwanted)

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)
No longer depends on: 157004
Interesting.  So, how do we deal with OnLocationChange then?
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.
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?
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.
Blocks: 216466
Assignee: adamlock → nobody
QA Contact: adamlock → docshell
Blocks: 623155
No longer blocks: 623155
Blocks: 623155
You need to log in before you can comment on or make changes to this bug.