Closed
Bug 1637689
Opened 5 years ago
Closed 5 years ago
enableAppmenuButton test fails
Categories
(Firefox :: Messaging System, defect)
Firefox
Messaging System
Tracking
()
RESOLVED
FIXED
Firefox 78
Tracking | Status | |
---|---|---|
firefox78 | --- | fixed |
People
(Reporter: thecount, Assigned: thecount)
Details
Attachments
(1 file)
Pretty sure there is a race condition in the tests for enableAppmenuButton.
It does these calls in "should registerCallback on enableAppmenuButton() if there are messages"
await instance.init(waitForInitializedStub, {
getMessages: sandbox.stub().resolves([{}, {}]),
});
// init calls `enableAppmenuButton`
everyWindowStub.registerCallback.resetHistory();
await instance.enableAppmenuButton();
assert.calledOnce(everyWindowStub.registerCallback);
In init, it's calling enableAppmenuButton, then it resets it, then calls it directly. Expecting it to only be called once.
However, the enableAppmenuButton call in init isn't await, and probably should be.
What I think that means is the call to enableAppmenuButton in init can finish after resetHistory, causing the test to fail with two calls.
I think.
If I add await to the call in init, the test fails go away.
I can make a patch.
Assignee | ||
Comment 1•5 years ago
|
||
Updated•5 years ago
|
Assignee: nobody → sdowne
Status: NEW → ASSIGNED
Pushed by sdowne@getpocket.com:
https://hg.mozilla.org/integration/autoland/rev/ff83ad726427
Await for enableAppmenuButton in init in ToolbarPanelHub.jsm r=emcminn
Comment 3•5 years ago
|
||
bugherder |
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
status-firefox78:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 78
You need to log in
before you can comment on or make changes to this bug.
Description
•