Show old uri when loading error page from Intent URIs rather than error page uri

NEW
Unassigned

Status

()

3 years ago
3 years ago

People

(Reporter: mcomella, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

bug 1162372 introduced error pages when loading intent URIs without application handlers, but opens the error page with the "about:neterror" uri. It'd be better if this was the old page's uri.

Discussion from bug 1193580 to follow.
(In reply to Andrzej Hunt :ahunt from bug 1193580 comment #3)
> But, another thing I was looking at was loading the error page without
> having to reveal the about:neterror?e=...&u=foo:bar url in the address bar
> (i.e. keeping "foo:bar" in the address bar if it's unloadable, while still
> showing the about:neterror page).
> 
> For certificate and loading errors, the url of the original page being
> loaded is still displayed in the address bar (as opposed to displaying
> about:certerror/neterror, which is what is loaded in the background),
> whereas here the (non-openable) url is overwritten with the about:neterror
> url - it would probably be nicer to keep the desired url showing in the url
> bar? (I.e. if we try to load, but can't open foo:bar, we still have
> "foo:bar" instead of about:neterror?e=....&u=foo:bar in the address bar.)
> 
> It seems to be quite tricky to actually do that though - right now the only
> place that we load about:certerror/neterror in this way is in nsDocShell,
> using LOAD_FLAGS_ERROR_PAGE to avoid overwriting the desired page url. This
> flag is [1] an internal only define, and only parsed in
> nsDocShell::InternalLoad [2] which is native only - it seems like we're only
> able to access nsDocShell::LoadURI from js code, which only passes a limited
> selection of flags on to InternalLoad [3].
> 
> It doesn't seem like it would be difficult to expose LOAD_FLAGS_ERROR_PAGE
> to frontend js - but I'm guessing that's not a good idea security-wise? (I'm
> quite new to the codebase though, so don't have much of a clue in this area,
> and might also have misunderstood the other bits of code I've read.)

This is probably not exposed because it just wasn't exposed before.

Daniel, do you think exposing LOAD_FLAGS_ERROR_PAGE to ContentDispatchChooser [4] could be a security risk? That is, if it's even possible – my gecko JS isn't good enough to know which object we could make this access from.

[1] http://mxr.mozilla.org/mozilla-central/source/docshell/base/nsDocShellLoadTypes.h#19
[2] http://mxr.mozilla.org/mozilla-central/source/docshell/base/nsDocShell.cpp#10379
[3] http://mxr.mozilla.org/mozilla-central/source/docshell/base/nsDocShell.cpp#1635

[4]: http://mxr.mozilla.org/mozilla-central/source/mobile/android/components/ContentDispatchChooser.js#74
Flags: needinfo?(dveditz)
Do you get access to the DocShell anywhere? If you can call LoadURI can you call nsDocShell::DisplayLoadError()?
Flags: needinfo?(dveditz)
Snorp, is it possible to access DocShell in the ContentDispatchChooser context?
Flags: needinfo?(snorp)
(In reply to Michael Comella (:mcomella) from comment #3)
> Snorp, is it possible to access DocShell in the ContentDispatchChooser
> context?

Yeah, see for example here: https://dxr.mozilla.org/mozilla-central/source/browser/base/content/browser.js#4709

You should be able to call displayLoadError on that directly: https://dxr.mozilla.org/mozilla-central/source/docshell/base/nsIDocShell.idl#459
Flags: needinfo?(snorp)
You need to log in before you can comment on or make changes to this bug.