1797390 - Test bustage for BrowserTestUtils.promiseAlertDialog()

Status: RESOLVED FIXED

(Thunderbird :: Testing Infrastructure, defect)

Description

[Alessandro Castellani [:aleca]]

Thunderbird tests using BrowserTestUtils.promiseAlertDialog() are failing with:
can't access property "accept", this._buttons is undefined - stack: getButton@chrome://global/content/elements/dialog.js

Making this method sync again fixes the tests.

I'm not sure why and how is this happening.

This seems to be related to bug 1708090, but bug 1796408 made the existing issue bubble up.

Comment 1

[Alessandro Castellani [:aleca]]

It seems that the tests that are failing are those using a dialog that was converted to a top level HTML from bug 1703164, while all other tests interacting with a <window> dialog seem to not have any problem with BrowserTestUtils.promiseAlertDialog().
I checked only a bunch of calendar related tests, so I might be wrong, but this seems to be the pattern, also no failures on m-c as it looks like they only have <window> dialogs and not top level HTML dialogs.

Comment 2

[Magnus Melin [:mkmelin]]

I suspect this is related to bug 1752288.
I didn't have time to go to the bottom of it, but when converting to top level html (bug 1703164) the buttons not being defined (yet) problem has popped up some times. We've worked around it by adding the scripts after the <xul:dialog> - https://searchfox.org/comm-central/search?q=bug%201752288
AFAIR, it's likely a bug in the xul dialog.js that triggers due to slightly different timings/load sequence for top level html vs top level xul.

Comment 3

[Alessandro Castellani [:aleca]]

Attachment: Bug 1797390 - Move scripts that cannot be deferred into the body of a top level html dialog. r=mkmelin

Comment 4

[Emilio Cobos Álvarez [:emilio]]

So... if I understand the log, the only way this._buttons can be undefined is if the connectedCallback for the dialog hasn't run by the time the load event has fired... Which doesn't make a whole lot of sense?

Comment 5

[Alessandro Castellani [:aleca]]

try run with the hacky fix: https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=9d1801973053c506c24e6c1ea2492bdf616caba8

Comment 6

[Alessandro Castellani [:aleca]]

And now this doesn't work anymore: https://searchfox.org/comm-central/rev/e7b7f18daf828a0cd92ff4394fa5dd7d66b76ac7/calendar/test/ItemEditingHelpers.jsm#535-539

Comment 7

[Magnus Melin [:mkmelin]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #4)

So... if I understand the log, the only way this._buttons can be undefined is if the connectedCallback for the dialog hasn't run by the time the load event has fired... Which doesn't make a whole lot of sense?

See bug 1752288. That's what happens atm.

Comment 8

[Magnus Melin [:mkmelin]]

Note to self: The failures without the patch seem to be:
comm/calendar/test/browser/recurrence/browser_daily.js
comm/mail/test/browser/composition/browser_attachmentCloudDraft.js
comm/mail/test/browser/folder-display/browser_messageCommandsOnMsgstore.js
comm/mail/test/browser/folder-pane/browser_folderPaneConsumers.js
comm/calendar/test/browser/recurrence/browser_annual.js
comm/calendar/test/browser/eventDialog/browser_eventDialog.js #unrelated?
comm/calendar/test/browser/providers/browser_caldavCalendar_cached.js
comm/mail/test/browser/composition/browser_attachmentReminder.js
comm/calendar/test/browser/recurrence/browser_customMinimonthCount.js # unrelated? fails locally with m-c patch

Comment 9

[Magnus Melin [:mkmelin]]

Did a fix for the dialog code. Try looks happy with that. https://treeherder.mozilla.org/jobs?repo=try-comm-central&selectedTaskRun=HewTtF48RmePE4IsbEZ-bg.0&revision=093d93910e0d7f0c62072d66d4d5dc67f2c19a63
I will clean it up and submit it to bug 1752288.

Comment 10

[Magnus Melin [:mkmelin]]

Bug 1752288 took care of this.