1650253 - Test permafails in headless mode only: toolkit/components/passwordmgr/test/browser/browser_doorhanger_toggles.js | FAIL Uncaught exception - [Exception... "(null)" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "<unknown>" data: no]

Status: RESOLVED WORKSFORME

(Toolkit :: Password Manager, defect, P2)

Description

[Bianca Danforth [:bdanforth]]

Attachment: FAIL_browser_doorhanger_toggles_debug_artifact_headless_2d709e60c76e.txt

In today's latest central, 2d709e60c76e, the browser mochitest toolkit/components/passwordmgr/test/browser/browser_doorhanger_toggles.js permafails if run in headless mode in an opt or debug artifact build (debug logs attached for headless mode failure):

FAIL Uncaught exception - [Exception... "(null)"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "<unknown>"  data: no]

This causes a test timeout failure which is inconvenient for any developer running password manager tests locally in headless mode and a waste of resources on the Try server (though headless mode for this test doesn't appear to run by default in automation).

Even though the failure occurs around await submittedPromise;1 in the first task ("test_toggle_password"), according to the logs, that promise resolves just before the failure occurs.

Others have reproduced this same failure, though it may occur later on in the test in a different task, it similarly happens just after await submittedPromise;.

While the root cause is TBD, it is definitely a timing issue, as adding two console.log statements on either side of this line caused the test to pass.

Comment 1

[Bianca Danforth [:bdanforth]]

Attachment: PASS_browser_doorhanger_toggles_debug_artifact_normal_2d709e60c76e.txt

Logs for the same test for the same debug artifact build, which passes in normal (i.e. not headless) mode.

Comment 2

[Matthew N. [:MattN]]

0:11.89 GECKO(94283) [Child 94286, Main Thread] WARNING: '!mCanSend || !mManager || !mManager->CanSend()', file /builds/worker/checkouts/gecko/dom/ipc/JSWindowActorChild.cpp, line 78

I guess this is the reason.

Comment 3

[Bianca Danforth [:bdanforth]]

This actually is passing now in headless mode at bca48c382991, so I'm going to resolve this for now...

If I had infinite time, I would do a mozregression to see what patch(es) fixed it, but I'll leave that for another day.