Follow-up of Bug 1543725: Fix starting marionette on macos
Categories
(Thunderbird :: Testing Infrastructure, task)
Tracking
(Not tracked)
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.
|
||
Updated•5 years ago
|
|
||
Comment 1•5 years ago
|
||
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?
|
||
Comment 2•5 years ago
|
||
|
|
||
Updated•5 years ago
|
|
|
||
Comment 3•5 years ago
|
||
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.
|
Reporter | |
Comment 4•5 years ago
|
||
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
|
|
||
Comment 5•5 years ago
|
||
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.
|
|
Reporter | |
Comment 6•5 years ago
|
||
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.
|
|
||
Comment 7•5 years ago
|
||
What happened to the patches from bug 1530980? I cannot find marionette-startup-requested anywhere in comm-central.
|
|
||
Comment 8•5 years ago
|
||
|
|
||
Comment 9•5 years ago
|
||
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.
|
|
Reporter | |
Comment 10•5 years ago
|
||
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
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.
|
|
Reporter | |
Comment 11•5 years ago
|
||
I found some fixes, doing some tries, I will submit something next week.
|
|
Reporter | |
Comment 12•5 years ago
|
||
|
|
Reporter | |
Comment 13•5 years ago
|
||
|
|
||
Comment 14•5 years ago
|
||
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®exp=false&path=test
|
|
||
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
|
||
Comment 15•5 years ago
|
||
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
|
|
||
Comment 16•5 years ago
|
||
Great to see that Marionette is working now also on MacOS.
Description
•