docshell error pages don't see the post-redirect URL when the redirect URL is invalid
Categories
(Core :: DOM: Navigation, defect, P3)
Tracking
()
People
(Reporter: mattwoodrow, Unassigned)
References
()
Details
DocumentChannel doesn't expose redirects to the originating nsDocShell, it just gets replaced with the final channel.
In the case where we have an http redirect, and then hit an error, the docshell just sees the resulting error code, and not that it occurred on a different URL to what we started with.
In the attached link (which redirects http to an unknown protocol), the generated error page reports that http is an unsupported protocol, since it doesn't know that the error came from a redirect.
|
Reporter | |
Comment 1•5 years ago
|
||
I think there's at least two possible solutions.
When we hit an error case in DocumentChannel and send back the error code, we could also include the final URL. We'd add a nsURI parameter to PDocumentChannel::DisconnectChildListener, and make this available to the docshell.
We could possible update the value of nsIChannel::URI for the DocumentChannelChild, but it's a bit weird for that to silently change. We could also just QI to DocumentChannelChild (as we do in a few places) and query the 'final' URI.
Another alternative would be moving the logic for deciding which error page to load into DocumentLoadListener, so that we decide that in the parent too. That's a little more involved, but might be the right long term solution.
|
||
Comment 2•5 years ago
|
||
Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)
|
||
Comment 3•4 years ago
|
||
Does this DocumentChannel bug need to block shipping Fission MVP?
|
|
||
Comment 4•4 years ago
|
||
Tracking for Fission M6c Nightly. Not urgent but definitely blocks Fission Nightly.
Nika wonders if this has already been fixed. This code has changed a lot over the past few months.
|
|
Reporter | |
Comment 5•4 years ago
|
||
This only happens if the redirect URL is entirely invalid, and we can't create a new channel object for it (like the example in the URL bugzilla field, which uses an invalid protocol).
It also happens without DocumentChannel enabled, so it's not a DocumentChannel or fission specific bug.
It we can't create the new channel for a redirect, then the error is reported as coming from the old channel. The error page loading code inspects the failing channel for the URI (which is pre-redirect), and uses that to fill details in the error page.
We might need a 'dummy' channel instance to act as a placeholder, or expose a new api on nsIHttpChannel to get the redirect url that we attempted (and maybe a specific error code that lets us know to check).
Description
•