1491443 - Navigation always hangs in window opened with "window.open()" from an extension page

Status: NEW

(WebExtensions :: General, defect, P5)

Description

[Alexei]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.92 Safari/537.36

Steps to reproduce:

1. Launch Firefox with Privacy Badger (using web-ext for example)
2. Visit Badger's background page (replace the path in the new user intro page or the options page with "_generated_background_page.html").
3. Open the console (Ctrl-Shift-K) and run window.open()
4. Try to navigate anywhere on the Web in the new window.

This bug is new to Firefox 63 (currently in Beta and Nightly).

Originally filed as https://github.com/mozilla/geckodriver/issues/1366.


Actual results:

The tab displays its "loading" indicator but nothing else happens.


Expected results:

Navigation should proceed.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This somewhat sounds similar to what we fixed for Firefox 63 via bug 1465388, but it is still happening for people.

Robert or Kris, could one of you please have a look?

Comment 2

[Rob Wu [:robwu]]

Background pages cannot use window.open().

I can reproduce this from an extensions page, under the following conditions:
- browser.link.open_newwindow=2 
- extensions.webextensions.remote=true
- open a new window in the same process:
  <a href="about:blank" target="_blank">link</a>

- This causes a tab to be opened in a non-extension process, and the bug does not occur:
  <a href="about:blank" target="_blank" rel="noopener">link</a>
  <a href="http://example.com/" target="_blank">link</a>

Comment 3

[Rob Wu [:robwu]]

Attachment: open-blank-window-from-extension.zip

STR:

1. Start Firefox with extensions.webextensions.remote=true (default on Nightly), and browser.link.open_newwindow=2
1. Visit about:debugging and load the extension.
   The extension will open an extension page in a new tab.
2. Click on the (first) "Link to about:blank" link.
3. In the window with the blank page that opens, focus the location bar and enter a website (e.g. example.com)

Expected result:
- example.com loads

Actual result:
- page load never completes

Comment 4

[Rob Wu [:robwu]]

When this bug occurs, the location bar becomes unusable: it cannot be focused, text selection does not work (even via the context menu).

The navigation cannot visually be aborted (X button / Home button).

When I start netcat and try to navigate to localhost at step 3, then I see that Firefox opens a connection to localhost, but never actually sends a HTTP request.


On Linux, this is a regression. mozregression confirms that the bug is related to OOP WebExtensions:

$ mozregression -b 63 -g 62 --arg=about:debugging --pref browser.link.open_newwindow:2
...
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1c52d8baf78986cb9497d48b8b88291686a681ca&tochange=c034e7ddbacdbe80ec8ce5b844e4299fcac9287c

Bug 1357487 is the commit where OOP WebExtensions was enabled by default on Linux.
On macOS, Firefox 62 was already affected by this bug.
When I turn of OOP WebExtensions on Nightly, the bug does not occur.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Great. Thank you for looking into that issue, Rob! I mark this bug as regression then.

Comment 6

[Andrew Swan [:aswan]]

The underlying problem is that without noopener, the new page is opening in the extension process.  Project Fission will address this, we're unlikely to do anything else to address it before that.  Your best bet in the mean time is to use the browser.windows or .tabs apis instead.

Comment 7

[Alexei]

I'm working around this Firefox bug in Privacy Badger's Selenium tests by creating, clicking and removing a "rel=noopener" link when open_window() is called on a moz-extension:// page: https://github.com/EFForg/privacybadger/commit/c94478a946616332c84a7788b3e3b1305e9f82a0

Comment 8

[Alexei]

I had to update Privacy Badger's workaround to use the chrome.windows API as it seems that we need to be able to wait until the window gets properly created to avoid race conditions: https://github.com/EFForg/privacybadger/pull/2193/commits/f95d8c2e67819ddaebdeff1d1ad2f3183092d341

Comment 9

[Pascal Chevrel:pascalc]

Updating tracking flags as we get closer to the 64 release, wontfix across the board as this is a P5 that should get fixed via project Fission (comment #6) which is a longer term project than our upcoming releases.