Closed Bug 1569118 Opened 2 years ago Closed 2 years ago

Follow-up of Bug 1543725: Fix starting marionette on macos

Categories

(Thunderbird :: Testing Infrastructure, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 70.0

People

(Reporter: samuel.thibault, Unassigned)

Details

Attachments

(1 file)

Marionette testing was added with Bug 1543725. We however had to disable testing on macos because thunderbird was not managing to reach marionette server start. This is probably due to some startup dialog box, such as disabled in testing/marionette/thunderbirdinstance.py, that would be specific to macos.

Type: -- → task

Where can I find the thunderbirdinstance.py file? Maybe it is the new account dialog which pops-up when no account has been setup yet? Or does that file create a temporary account to prevent that, or disables this dialog? Does anyone have some log files from automation, which show this problem?

Status: UNCONFIRMED → NEW
Ever confirmed: true

It's sad to see that we don't have that file in mozilla-central beside the other Marionette client files. As it is I cannot test it easily without having to clone comm-central. Also note (even we don't release Marionette client code anymore to PyPI) that this file wouldn't be part of the official Marionette client package.

So what happens when you start the tests locally? It should basically show the same problem as in CI.

The account creation part is handled by

"mail.provider.suppress_dialog_on_startup": True

and that works for linux & windows.

It's sad to see that we don't have that file in mozilla-central beside the other Marionette client files.

This was on purpose because if something needed to be added, it would be along a change in comm-central.

So what happens when you start the tests locally? It should basically show the same problem as in CI.

I don't have a macos box to test this unfortunately. The only thing I have is the test log here: https://taskcluster-artifacts.net/W_75WeHdTwucyJ6_SadVBA/0/public/logs/live_backing.log

which shows that nothing happens between

[task 2019-07-30T13:24:50.142Z] 13:24:50     INFO -  JavaScript error: chrome://messenger/content/msgViewPickerOverlay.js, line 95: TypeError: gFolderDisplay is null
[task 2019-07-30T13:26:48.555Z] 13:26:48    ERROR - Process killed after 120s because no connection to Marionette server could be established. Check gecko.log for errors

To be compared with e.g. https://taskcluster-artifacts.net/Wno0h7azRuO5DSCmjSvJ-A/0/public/logs/live_backing.log

Most likely it's this Javascript error which prevents further initialization of Thunderbird, and to get it to send out the marionette-startup-requested observer notification. I would suggest that someone fixes this error first.

I had already had a look at this, and I don't think it's releated. See try https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&selectedJob=259197625&revision=bf6dec9e08544fc4d18e72d773ba097150ce9a20 , in which I hacked around the JS issues, this is still getting stuck somehow.

What happened to the patches from bug 1530980? I cannot find marionette-startup-requested anywhere in comm-central.

I thought that I did reply right away but looks like the comment didn't make it.

By the time when I checked the code on comm-central I accidentally opened dxr and not searchfox. Looks like dxr is no longer updating it's content and as such I didn't see those commits.

The only suggestion I have right now is that you add debug/logging code to figure out where in the startup sequence the hang happens.

I have put various prints here and there, and ended up noticing that it's ext-legacy.js which seems to get stuck, as can be seen in the live_backing.log files of the Linux vs Macos Mn tasks in

https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=aa228ee5e98c44fc120c0e31e66d3107a2214a9e

We can notice that for messenger.xul, we have "beginning load of chrome://messenger/content/messenger.xul" (printed in Document::BeginLoad) and "EndLoad1 chrome://messenger/content/messenger.xul" and up to EndLoad9, printed in Document::EndLoad, but not EndLoad10, it is stuck in the Document::UnblockDOMContentLoaded call, itself stuck in Document::DispatchContentLoadedEvents call, itself stuck in the nsObserverService::NotifyObservers call. Prints in ext-legacy.js show that it is stuck in

Overlays.load(chromeManifest, document.defaultView);

In https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=0172d9759a5dcef672310f77b47f33fd60bfe287 I have tried to disable ext-legacy.js the hard way, it has indeed unstuck loading messenger.xul, and I don't see other documents not finishing loading, but still ./comm/mail/base/content/msgMail3PaneWindow.js's OnLoadMessenger() doesn't get called, I don't know why messenger.xul's onload="OnLoadMessenger()" doesn't kicks in.

I found some fixes, doing some tries, I will submit something next week.

Sigh, the Mac address book is interfering. That's why we already switch it off in various locations:
https://searchfox.org/comm-central/search?q=ldap_2.servers.osx.description&case=false&regexp=false&path=test

Target Milestone: --- → Thunderbird 70.0

Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/8bbeb44f15b3
Fix marionette startup on MacOS by disabling Mac address book integration. r=rjl DONTBUILD

Status: NEW → RESOLVED
Closed: 2 years ago
Keywords: checkin-needed
Resolution: --- → FIXED

Great to see that Marionette is working now also on MacOS.

You need to log in before you can comment on or make changes to this bug.