Bug 1682285 Comment 0 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

I've been trying to fix bug 1678255 by using the [load info's `loadTriggeredFromExternal`](https://searchfox.org/mozilla-central/rev/97dd1934d16cada69dbf68e9cda9e9a017459e9e/netwerk/base/nsILoadInfo.idl#829-834) property.

Unfortunately this appears not to work, because despite the tab addition from [browser.js](https://searchfox.org/mozilla-central/rev/97dd1934d16cada69dbf68e9cda9e9a017459e9e/browser/base/content/browser.js#5942,5946) passing the correct value to `addTab`, which [passes it](https://searchfox.org/mozilla-central/rev/97dd1934d16cada69dbf68e9cda9e9a017459e9e/browser/base/content/tabbrowser.js#1718-1720) into the loadState which [passes it to webnavigation](https://searchfox.org/mozilla-central/rev/97dd1934d16cada69dbf68e9cda9e9a017459e9e/toolkit/content/widgets/browser-custom-element.js#801-827), which [passes it to the browsingcontext](https://searchfox.org/mozilla-central/rev/97dd1934d16cada69dbf68e9cda9e9a017459e9e/toolkit/components/remotebrowserutils/RemoteWebNavigation.jsm#128-131).

That passes it down to the child, which ends up in `nsDocShell::LoadURI`, where it [calls `CalculateLoadURIFlags`](https://searchfox.org/mozilla-central/rev/97dd1934d16cada69dbf68e9cda9e9a017459e9e/docshell/base/nsDocShell.cpp#863) which seems to wipe the "from external" information, which then doesn't end up in the load info or loadstate that gets sent back to the parent via document channel construction, which means that by the time we get to the external helper app service in the parent, we no longer have this information and can't use it to make decisions.

I'm not sure how this is *supposed* to work, but it clearly doesn't right now... Nika or Matt, can you help clarify what is supposed to happen and how best to address this? Happy to write a patch but I'm a bit lost at the moment - is the roundtrip to the child even expected? Should we add an `INTERNAL_` docshell flag for the `LOAD_FLAGS_FROM_EXTERNAL` flag, or is it meant to be preserved some other way (how?).

In terms of STR:

1. `./mach run --remote`
2. `./mach run --remote --url 'mailto:foo@mozilla.com'`
I've been trying to fix bug 1678255 by using the [load info's `loadTriggeredFromExternal`](https://searchfox.org/mozilla-central/rev/97dd1934d16cada69dbf68e9cda9e9a017459e9e/netwerk/base/nsILoadInfo.idl#829-834) property.

Unfortunately this appears not to work, because despite the tab addition from [browser.js](https://searchfox.org/mozilla-central/rev/97dd1934d16cada69dbf68e9cda9e9a017459e9e/browser/base/content/browser.js#5942,5946) passing the correct value to `addTab`, which [passes it](https://searchfox.org/mozilla-central/rev/97dd1934d16cada69dbf68e9cda9e9a017459e9e/browser/base/content/tabbrowser.js#1718-1720) into the loadState which [passes it to webnavigation](https://searchfox.org/mozilla-central/rev/97dd1934d16cada69dbf68e9cda9e9a017459e9e/toolkit/content/widgets/browser-custom-element.js#801-827), which [passes it to the browsingcontext](https://searchfox.org/mozilla-central/rev/97dd1934d16cada69dbf68e9cda9e9a017459e9e/toolkit/components/remotebrowserutils/RemoteWebNavigation.jsm#128-131).

That passes it down to the child, which ends up in `nsDocShell::LoadURI`, where it [calls `CalculateLoadURIFlags`](https://searchfox.org/mozilla-central/rev/97dd1934d16cada69dbf68e9cda9e9a017459e9e/docshell/base/nsDocShell.cpp#863) which seems to wipe the "from external" information, which then doesn't end up in the load info or loadstate that gets sent back to the parent via document channel construction, which means that by the time we get to the external helper app service in the parent, we no longer have this information and can't use it to make decisions.

I'm not sure how this is *supposed* to work, but it clearly doesn't right now... Nika or Matt, can you help clarify what is supposed to happen and how best to address this? Happy to write a patch but I'm a bit lost at the moment - is the roundtrip to the child even expected? Should we add an `INTERNAL_` docshell flag for the `LOAD_FLAGS_FROM_EXTERNAL` flag, or is it meant to be preserved some other way (how?).

In terms of STR:

1. `./mach run --remote`
2. once the browser finishes starting up, set a breakpoint in `DocumentChannelParent::Init`
3. `./mach run --remote --url 'mailto:foo@mozilla.com'`
4. inspect the loadstate / loadinfo that are passed as arguments.

Back to Bug 1682285 Comment 0