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  an internal only define, and only parsed in > nsDocShell::InternalLoad  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 . > > 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  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.  http://mxr.mozilla.org/mozilla-central/source/docshell/base/nsDocShellLoadTypes.h#19  http://mxr.mozilla.org/mozilla-central/source/docshell/base/nsDocShell.cpp#10379  http://mxr.mozilla.org/mozilla-central/source/docshell/base/nsDocShell.cpp#1635 : http://mxr.mozilla.org/mozilla-central/source/mobile/android/components/ContentDispatchChooser.js#74
Do you get access to the DocShell anywhere? If you can call LoadURI can you call nsDocShell::DisplayLoadError()?
Snorp, is it possible to access DocShell in the ContentDispatchChooser context?
(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
You need to log in before you can comment on or make changes to this bug.