browser_elevationDialog.js fails standalone due to uninitialized UpdateServiceStub causing extra elevation dialog
Categories
(Toolkit :: Application Update, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox151 | --- | fixed |
People
(Reporter: florian, Assigned: florian)
References
Details
Attachments
(1 file)
browser_elevationDialog.js fails when run standalone but passes in the full folder.
The root cause is that when run standalone, the UpdateServiceStub has not been initialized (because app.update.disabledForTesting is true during browser startup). When the elevation dialog's onLoad calls getReadyUpdate() → AUS.init(), this triggers a full stub initialization including UpdateServiceStub.#initUpdate() → reload(false) + aus.internal.init(false). The init(false) creates a new #asyncInit() (since #initPromise was never cached — testPostUpdateProcessing() uses force=true which bypasses it). This extra #asyncInit() sees the pending-elevate state and schedules an extra elevation dialog via setTimeout. The extra dialog gets captured by the window listener for the next test iteration, and its onLoad crashes with update is null.
In folder runs, a previous test already initializes the stub, so the dialog's getReadyUpdate() returns immediately without triggering another init.
The fix is to add await gAUS.init() after setting PREF_APP_UPDATE_DISABLEDFORTESTING to false, ensuring the stub is initialized before elevation dialogs are opened.
Note: this bug description was written by Claude and I have not fully verified it, so take it more as a hint than as solid statement of facts. I have however verified that ./mach test toolkit/mozapps/update/tests/browser/browser_elevationDialog.js --headless fails locally without the patch, and ./mach test toolkit/mozapps/update/tests/browser/browser_elevationDialog.js --headless --verify passes locally with the patch.
| Assignee | ||
Comment 1•4 months ago
|
||
Updated•4 months ago
|
Comment 3•4 months ago
|
||
| bugherder | ||
Updated•3 months ago
|
Description
•