runtime.onMessage handler cannot return response asynchronously
Categories
(WebExtensions :: General, defect)
Tracking
(firefox-esr68 unaffected, firefox77 unaffected, firefox78 unaffected, firefox79 fixed)
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox77 | --- | unaffected |
firefox78 | --- | unaffected |
firefox79 | --- | fixed |
People
(Reporter: yuki, Assigned: zombie)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
I still couldn't find out the minimum condition to reproduce, but there is a reproducibility on a real addon, so I report this.
On some situations runtime.onMessage
listener cannot return a response asynchronously via a Promise. When the problem happens the sender simply gets undefined
response unexpectedly and immediately, even if the promise returned by a listener is not resolved yet.
Steps to reproduce
I've tried these steps with the mozregression for mozilla-central builds between 2020-05-31 and 2020-06-01.
- Start Nightly.
- Install the addon: https://addons.mozilla.org/ja/firefox/addon/tree-style-tab/
- A sidebar panel provided by the addon is loaded. Please do all following steps on the sidebar.
- Open two more blank tabs and construct a tree of tabs by drag and drop. Assume that finally there are three tabs:
- Tab A (initially opened tab)
- Tab B (startup tab opened by the addon automatically)
- Tab C (1st new blank tab)
- Tab D (a child of C, 2nd new blank tab)
- Collapse a tree by clicking the down chevron of the tab C.
- Middle-click on the tab C (or click the "X" button of the tab C) to close the tree.
- The addon shows a confirmation dialog to close multiple tabs. Chose the "Close tabs" button in the dialog.
Expected result
- Tabs C and D are closed.
Actual result
- Tabs C and D are still there.
Background of the problem
What expectedly happens when you try to close tabs is:
- The sidebar panel sends a message to the background page via
runtime.sendMessag()
. - The listener in the background page receives the message and returns a Promise.
- The background page shows a confirmation dialog.
- After the dialog is closed, the Promise returned at the step 2 is resolved with the result.
- The sidebar panel gets the resolved result, and sends another message to request close tabs to the background page based on the resolved result.
On the other hand, what actually happens is:
- The sidebar panel sends a message to the background page via runtime.sendMessag().
- The listener in the background page receives the message and returns a Promise.
- The sidebar panel gets a value undefined as the resolved result, and gives up to continue post processes.
- The background page shows a confirmation dialog.
- After the dialog is closed, the Promise returned at the step 2 is resolved with the result.
Environment
Windows 10, the information shown in the mozregression for the first bad build:
app_name: firefox
build_date: 2020-06-01
build_file: C:\Users\***\.mozilla\mozregression\persist\2020-06-01--mozilla-central--firefox-79.0a1.en-US.win64.zip
build_type: nightly
build_url: https://archive.mozilla.org/pub/firefox/nightly/2020/06/2020-06-01-21-42-28-mozilla-central/firefox-79.0a1.en-US.win64.zip
changeset: bc973d369db58faf254ddcef201089dc28e6d3be
pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=548ffce7ad571850fdcb024ae3459855230ebd35&tochange=bc973d369db58faf254ddcef201089dc28e6d3be
repo_name: mozilla-central
repo_url: https://hg.mozilla.org/mozilla-central
Reporter | ||
Comment 1•3 years ago
|
||
I've added links to corresponding codes of the addon on each step.
Reporter | ||
Comment 2•3 years ago
|
||
The addon contains many runtime.onMessage
listeners, and they are designed to return nothing when the listener is not for the notified message. So always only one (or no) listener returns a Promise for the response. When the problem happens, the returned promise of runtime.sendMessage()
looks to be resolved with a returned value undefined
from unrespond listeners.
Assignee | ||
Comment 3•3 years ago
|
||
Thank you Yuki for the report, this is probably related to bug 1583484, and similar to 1642967.
We're investigating, and if you do manage to create a reduced STR, that would still speed things up.
Reporter | ||
Updated•3 years ago
|
Reporter | ||
Comment 5•3 years ago
|
||
Thanks, I've realized that this is quite same to the bug 1643186.
Assignee | ||
Comment 6•3 years ago
|
||
I'm reopening this, since this is an actual regression, and bug 1643186 was present in earlier versions of Firefox.
It is possible the patch from bug 1583484 made bug 1643186 more common/apparent, but that's a separate issue then, at least for now.
Still need to investigate the cause here.
Updated•3 years ago
|
Assignee | ||
Comment 7•3 years ago
|
||
Updated•3 years ago
|
Comment 8•3 years ago
|
||
Set release status flags based on info from the regressing bug 1583484
Pushed by tjovanovic@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/1d079340cfce Wait for explict responses from runtime.onMessage r=mixedpuppy
Comment 10•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Assignee | ||
Comment 11•3 years ago
|
||
Hi Yuki, could you please verify if everything works as expected with TST in latest Nightly? I confirmed the original problem is not present anymore, but I'm not sure if that was the only issue.
Reporter | ||
Comment 12•3 years ago
|
||
Sorry for this delay, I've confirmed that I cannot reproduce the problem on TST anymore with Nightly 79.0a1 Build ID 20200618094105!
Description
•