1418655 - browser.tabs.onUpdated status == "complete" fires before tab can receive messages

Status: REOPENED

(WebExtensions :: Frontend, defect, P3)

Description

[Dave Vandyke]

Attachment: firefox-onupdated-complete-problem.tar.gz

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

Steps to reproduce:

1. Extract the attached archive, load as temporary extension.



Actual results:

The extension creates a popup window, but the popup window does not display an alert. The following message is displayed in the extension's console:

Error: Could not establish connection. Receiving end does not exist.  undefined


Expected results:

The popup window should display an alert message when it receives the message sent from the background page.


Notes:

- On Windows 10 the problem is reproducible, but on Linux (Debian Buster) it is not.
- Related Adblock Plus issue: https://issues.adblockplus.org/ticket/5817

Comment 1

[Dave Vandyke]

Sorry I forgot to mention I'm using Firefox 57.0 on both Linux and Windows.

Comment 2

[Dave Vandyke]

I can also reproduce the bug on Linux by setting extensions.webextensions.remote to true and restarting Firefox.

Comment 4

[Wladimir Palant]

Kris, how can this be a duplicate? This bug is about a timing issue with OOP extensions, not a general limitation.

Comment 5

[Kris Maglione [:kmag]]

I don't see how it can be a timing issue when this is not supported at all.

Comment 6

[Wladimir Palant]

Feel free to try the code that supposedly "is not supported at all" on Linux or on Windows with extensions.webextensions.remote preference turned off - it definitely does work. And it works on Windows as well if a delay is added. I don't know whether bug 1209869 is describing a different scenario or is simply outdated, but it being an issue we never noticed I would assume the latter.

Comment 7

[Wladimir Palant]

Reopening this bug, with bug 1209869 now established as WORKSFORME as of Firefox 51.

Comment 8

[Rob Wu [:robwu]]

Can confirm, on Linux, even on today's Nightly.

This specific test case is failing because tabs.onUpdated is fired for the initial about:blank.
When I add: != "about:blank", then the test passes.

Extensions likely expect the following (behavior in Chrome):

windows.create({url})
// callback: win.tabs[0].url == url.

onUpdated {status: "loading", url} for url.
onUpdated {status: "complete"} for url.

With popups, we have the following:
windows.create({url})
// callback win.tabs[0].url == "about:blank" and status == "complete".

onUpdated {status: "loading"} for "about:blank"
onUpdated {status: "complete"} for "about:blank"
onUpdated {status: "loading", url} for url
onUpdated {status: "complete"} for url

When I use tabs.create instead, there is no onUpdated with changeInfo.status="complete", but that is probably a timing issue.
tabs.executeScript already accounts for tab loads via tabs.create, but not for tab loads via windows.create:

Pass:
browser.tabs.create({url:'https://example.com'}).then(tab=>browser.tabs.executeScript(tab.id,{runAt:'document_start',code:'alert(document.URL)'}))

Fail:
browser.windows.create({url:'https://example.com'}).then(({tabs:[tab]})=>browser.tabs.executeScript(tab.id,{runAt:'document_start',code:'alert(document.URL)'}))

We should probably have this kind of logic in windows.create too:
https://searchfox.org/mozilla-central/rev/99cbc0aec3e1c0b65ff9052523fb5c181b248f57/browser/components/extensions/parent/ext-tabs.js#651-655