1521933 - location.replace from a WebExtension leaves source page in history

Status: RESOLVED DUPLICATE of bug 1436321

(WebExtensions :: General, defect)

Description

[quasicomputational]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:64.0) Gecko/20100101 Firefox/64.0

Steps to reproduce:

1. Load the WebExtension described at https://gist.github.com/quasicomputational/ec09c7c71ea6bbfa2be513c67fa7c8a9
2. Navigate to any page (e.g., https://bbc.co.uk)
3. Click the extension's icon in the toolbar (the red circle) and find yourself at example.com
4. Click the back button.

Actual results:

You're unable to leave https://example.com for more than a fraction of a second by the 'back' button.

Expected results:

The back button should have worked and taken you back to the page you were on before.

window.location.replace should replace the current page with the destination page in the forwards/back history, and this works for Web content, but, if the calling context has WebExtension privileges (in this instance, it's a moz-extension URL), it seems to be trouble.

Bug 1436321 may be related: in that one, it's going in the opposite direction, where the navigation is to a WebExtension page and the previous page is unexpectedly left in history.

Discussion at https://github.com/uBlockOrigin/uMatrix-issues/issues/100 suggests that (a) Chromium is unaffected, and (b) this bug sometimes doesn't happen on Firefox.

Comment 1

[Luca Greco [:rpl] [:luca] [:lgreco]]

I took a brief look into how the window.location.replace is being handled in this case (when it is called from an extension tab page and it points to a regular webpage url), and the reason seems to be the following:

• nsIDocShell::InternalLoad calls WebBrowserChrome.shouldLoadURI to check if the current docshell can load the URI

• the extension tab is running in the "WebExtension" process, but the target "http://example.com" url can't be loaded in that process because it is a regular webpage url and it should be loaded in the "WebContent" process, and so tab-content.js (where shouldLoadURI is implemented) will return false after it has also called E10SUtils.redirectLoad(aDocShell, aURI, aReferrer, aTriggeringPrincipal, false);, which asks the main process to load the "http://example.com" in the expected process.

The above E10SUtils.redirectLoad doesn't provide to the main process any loadFlags (which could allow the main process to know if that url should be loaded as a new entry in the history or if it should replace the current entry), as WebBrowserChrome.shouldLoadURI doesn't receive that information from the caller.

As a workaround, given that location.replace is being called from an extension page, the extension can call the browser.tabs.update API method with the additional loadReplace option from the extension tab page (instead of location.replace):

browser.tabs.update({url: "http://example.com", loadReplace: true});

Comment 2

[Luca Greco [:rpl] [:luca] [:lgreco]]

I'm duping this issue to Bug 1436321, as the underlying issue described in comment 1 and the one described in Bug 1436321 comment 5 (and confirmed in Bug 1436321 comment 6) are the same.