Closed Bug 1643214 Opened 3 years ago Closed 3 years ago

runtime.onMessage handler cannot return response asynchronously

Categories

(WebExtensions :: General, defect)

Product:
WebExtensions
Component:
General
Type:
defect

Tracking

(firefox-esr68 unaffected, firefox77 unaffected, firefox78 unaffected, firefox79 fixed)

Status:
VERIFIED FIXED
Milestone:
mozilla79
Tracking Flags:
Tracking Status
firefox-esr68 --- unaffected
firefox77 --- unaffected
firefox78 --- unaffected
firefox79 --- fixed

People

(Reporter: yuki, Assigned: zombie)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

Bug 1643214 - Wait for explict responses from runtime.onMessage
47 bytes, text/x-phabricator-request
Details | Review

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.

  1. Start Nightly.
  2. Install the addon: https://addons.mozilla.org/ja/firefox/addon/tree-style-tab/
  3. A sidebar panel provided by the addon is loaded. Please do all following steps on the sidebar.
  4. 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)
  5. Collapse a tree by clicking the down chevron of the tab C.
  6. Middle-click on the tab C (or click the "X" button of the tab C) to close the tree.
  7. 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:

  1. The sidebar panel sends a message to the background page via runtime.sendMessag().
  2. The listener in the background page receives the message and returns a Promise.
  3. The background page shows a confirmation dialog.
  4. After the dialog is closed, the Promise returned at the step 2 is resolved with the result.
  5. 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:

  1. The sidebar panel sends a message to the background page via runtime.sendMessag().
  2. The listener in the background page receives the message and returns a Promise.
  3. The sidebar panel gets a value undefined as the resolved result, and gives up to continue post processes.
  4. The background page shows a confirmation dialog.
  5. 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

I've added links to corresponding codes of the addon on each step.

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.

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.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE

Thanks, I've realized that this is quite same to the bug 1643186.

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.

Status: RESOLVED → REOPENED
Regressed by: 1583484
Resolution: DUPLICATE → ---
Has Regression Range: --- → yes
Assignee: nobody → tomica

Set release status flags based on info from the regressing bug 1583484

status-firefox77: --- → unaffected
status-firefox78: --- → unaffected
status-firefox79: --- → affected
status-firefox-esr68: --- → unaffected
Pushed by tjovanovic@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1d079340cfce
Wait for explict responses from runtime.onMessage r=mixedpuppy

https://hg.mozilla.org/mozilla-central/rev/1d079340cfce

Status: REOPENED → RESOLVED
Closed: 3 years ago → 3 years ago
status-firefox79: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla79

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.

Flags: needinfo?(yuki)

Sorry for this delay, I've confirmed that I cannot reproduce the problem on TST anymore with Nightly 79.0a1 Build ID 20200618094105!

Status: RESOLVED → VERIFIED
Flags: needinfo?(yuki)
You need to log in before you can comment on or make changes to this bug.