Should background pages be allowed to navigate?

[xeenon]

Based on testing, it seems Chrome 90+ blocks navigations in the background page, while Firefox 88+ allows it. Safari 14+ also allows navigation.

[Jack-Works]

I'm wondering what use case you need to navigate the background page 👀

[Rob--W]

I don't see a purpose in navigation from extension pages to destinations from a different origin, and I recommend blocking it. One may also consider navigation destinations that are same-origin. There may not be that much point in blocking that, since an extension could also load a same-origin iframe that has the same scripting capabilities.

There is a tracking bug for Firefox about removing the ability to navigate the background to a remote URL at https://bugzilla.mozilla.org/show_bug.cgi?id=1286083 (which I have filed 6 years ago).

For completeness, could the following questions be answered?

1. What happens when window.close(); is called from a background page / event page?
2. What happens when the background page navigates to the same URL (reload)?
3. What happens when the background page navigates to a non-existing extension URL?
4. What happens when the background page navigates to about:blank?
5. What happens when the background page navigates to a blob:-URL with the extension origin?
6. What happens to the value in browser.extension.getViews() and await browser.runtime.getBackgroundPage() / browser.extension.getBackgroundPage() after a navigation?

Currently, Firefox accepts the navigation request in all of the above cases. Same-origin extension documents do appear in browser.extension.getViews() and browser.runtime.getBackgroundPage(). This behavior is a consequence of the current implementation, and there is no test coverage for it.

What is the actual behavior in Safari and Chrome?

[Rob--W]

As mentioned in the meeting notes (#202), the resolution is that remote navigations should be disallowed, and same-origin navigations (including reloads) be allowed. To minimize backwards-compatibility issues, it's worth trying this in MV3 instead of immediately in MV2 too.

[dotproto]

As a quick point of clarity, we are not planning to change how we handle background page navigation in Chrome. As I recall the resolution to limit background page navigation to same-origin was limited to Firefox and Safari. Of course, please correct me if I'm wrong.

[Rob--W]

As a quick point of clarity, we are not planning to change how we handle background page navigation in Chrome. As I recall the resolution to limit background page navigation to same-origin was limited to Firefox and Safari. Of course, please correct me if I'm wrong.

I said that only Firefox and Safari had to be changed, because Chrome already has the strict behavior, and that in MV3 Chrome is currently not supporting event pages/background pages, which implies that there is not much to change.

I just checked again in Chrome 100: Chrome does not allow navigation of the background page at all, only location.reload() works. window.close() just closes the page (iframes can be loaded, navigations with target to that frame or _blank work too - in the latter case a new tab is opened).
So instead of also permitting same-origin navigations, we could block navigations altogether.

@xeenon What do you think? Would you be in favor of blocking navigations altogether?