Closed Bug 1493770 Opened 6 years ago Closed 6 years ago

AsyncShutdown timeout in asyncEmitManifestEntry("chrome_settings_overrides")


(WebExtensions :: General, defect, P1)



(firefox-esr60 unaffected, firefox63 wontfix, firefox64 wontfix, firefox65 verified, firefox66 verified, firefox67 verified)

Tracking Status
firefox-esr60 --- unaffected
firefox63 --- wontfix
firefox64 --- wontfix
firefox65 --- verified
firefox66 --- verified
firefox67 --- verified


(Reporter: kmag, Assigned: mkaply)


(Blocks 1 open bug)


(Keywords: crash, regression)

Crash Data


(1 file)

This happens in particular with the DuckDuckGo search add-on:

    "conditions": [
            "filename": "resource://gre/modules/addons/XPIProvider.jsm",
            "lineNumber": 2211,
            "name": "Extension shutdown: jid1-ZAdIEUB7XOzOJw@jetpack",
            "stack": ["resource://gre/modules/addons/XPIProvider.jsm:startup/<:2211"],
            "state": {"state": "Startup: Run manifest: asyncEmitManifestEntry(\"chrome_settings_overrides\")"}
    "phase": "profile-change-teardown"
Flags: needinfo?(mozilla)
Can you give me some more details as to what this means?
Flags: needinfo?(mozilla)
(In reply to Mike Kaply [:mkaply] from comment #1)
> Can you give me some more details as to what this means?

The promise returned by the onManifest handler in the chrome_settings_override API never resolves for some users.
In the second case, the add-on was Ecosia.

What's odd is these are two very different scenarios. In the DuckDuckGo case, no engine is added (because it already exists).

In the second case, an engine is added

Where did your information come for the opening the original problem?

Is this something you were able to recreate?
Priority: -- → P1
From offline conversation with mkaply:

Which suggests that one of the search-related promises isn't resolving in time (ie "await searchInitialized" or "await addSearchEngine()".  Is there some possible case where the search service "init-complete" event never gets fired?
Assignee: nobody → mozilla
Have a recreation scenario on Windows:

Create a new profile and make sure it doesn't show the "multiple tabs open" message on shutdown.

1. Use the web page method to install an add-on which includes a search engine (eg.
2. When the second prompt is showing, which is for the default search, close Firefox using the X button in the window title bar

If anything interferes with the closing of Firefox, it won't happen (dialog popup).

What you'll see is that multiple processes are left open in the task manager and after a minute or so, Firefox crashes
Crash Signature: [@ AsyncShutdownTimeout | profile-change-teardown | Extension shutdown:] [@ AsyncShutdownTimeout | profile-change-teardown | Extension shutdown:] [@ AsyncShutdownTimeout | profile-change-teardown | Extension shutdo…
Keywords: crash, regression
Pushed by
Switch WebExt default search prompt away from promise. r=aswan
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66

Is this something we might consider taking in a 65 RC build or is it safer at this point to just let it ride with 66?

Flags: needinfo?(mozilla)

This is super trivial. I'd suggest taking it.

I'm personally torn. On the one hand, it hasn't been seen a lot, on the other hand it's a crasher.

As Kris said, it's a pretty trivial patch.

Flags: needinfo?(mozilla)

Comment on attachment 9035795 [details]
Bug 1493770 - Switch WebExt default search prompt away from promise.

[Beta/Release Uplift Approval Request]

Feature/Bug causing the regression: None

User impact if declined: Occasional crash when extension with search engine is installed.

Is this code covered by automated tests?: Yes

Has the fix been verified in Nightly?: No

Needs manual test from QE?: Yes

If yes, steps to reproduce: See

Works on Mac too.

List of other uplifts needed: None

Risk to taking this patch: Low

Why is the change risky/not risky? (and alternatives if risky): Refactors very self contained code.

String changes made/needed:

Attachment #9035795 - Flags: approval-mozilla-release?
Flags: qe-verify+

This issue appears to only be reproducible on Windows platform. Is this correct?

In any case, the issue was reproduced on Nightly v66.0a1 from 20190115 and Windows 10 and the fix is now verified on Nightly v66
.0a1 from 20190123 and Windows 10, using the str form comment 6. I will mark this bug as verified.

@Mike: Could this issue also be reproduced on other OSes than Windows? Could/Should I verify the fix on other OSes?

Thank you!

Flags: needinfo?(mozilla)

It is recreatable on Mac (you have to use the keystroke to close the app).

But Windows was most prevalent, so seeing that you are able to verify the fix worked, I think we're good.

Flags: needinfo?(mozilla)

Comment on attachment 9035795 [details]
Bug 1493770 - Switch WebExt default search prompt away from promise.

[Triage Comment]
Fixes an occasional crash when an extension with a search engine is installed. Verified by QA on nightly. Approved for 65.0 RC2.

Attachment #9035795 - Flags: approval-mozilla-release? → approval-mozilla-release+

i don't really see a decline of those crashes in 65.0rc2 - should we reopen the bug or follow up in a new one?

The MOZ_CRASH reason is now sanitized, and I don't have access to unsanitized probes, so I can't even begin to guess whether the crashes are still from this issue, or from another.

(In reply to Mike Kaply [:mkaply] from comment #19)

Are those this bug?

Bug 1464938 is an umbrella bug for all extension shutdown hangs, including this one.

OK, apparently there's an AsyncShutdownTimeout metadata field with the necessary information now. And this is definitely still a bug in chrome_settings_overrides, though perhaps in a different place now.

As an addition to comment 14, I have reproduced the issue on Mac OS 10.13.6 with Nightly v66.0a1 from 2019-01-15 (using the COMMAND + Q keystroke to quit the browser, and then verified the fix in Nightly v67.0a1 from 2019-01-30.

Furthermore, while continuing testing for uplift, the changeset from comment 17 is to the release channel, not to beta. I have reproduced the issue in Firefox Release v64.0 and then validated the fix on Firefox Release v65.0 on Windows 10 and Mac OS 10.13.6.
I have also verified the fix on the latest Nightly for certainty.

Thank you for your contribution!

Flags: qe-verify+
See Also: → 1525729
You need to log in before you can comment on or make changes to this bug.