1307070 - C-C TB: Error: Invalid addon ID: expected addon ID [e-mail], found [e-mail] in manifest

Status: NEW

(Thunderbird :: Testing Infrastructure, defect)

Description

[ISHIKAWA, Chiaki]

(first reported to dev-platform ML
https://groups.google.com/forum/m/#!topic/mozilla.dev.platform/5-TiFEZuehw

Note that this is not platform-dependent: windows, linux, OSX all have the error/warning messages.)

Quote from the first post.

While perusing error log of try-comm-central run of

Windows 7 debug version run of |make mozmill| test on try-comm-central treeherder, I noticed a strange error message.


3:07:56 INFO - 1474488476446 addons.xpi-utils WARN addMetadata: Add-on [e-mail] is invalid: Error: Invalid addon ID: expected addon ID [e-mail], found [e-mail] in manifest ...



I am not sure if this comes from the intended test.
Rather it looks a configuration error.

The error line seems to appear at beginning of the selected run of each test directory.


The error lines surrounding the "[e-mail] in manifest" are as follows.

I quote  from one instance of such error lines.


13:07:52 INFO - ['C:\\slave\\test\\build\\venv\\Scripts\\python.exe', 'runtest.py', '-t', 'keyboard', '--binary', 'C:\\slave\\test\\build\\application\\thunderbird\\thunderbird.exe', '--symbols-path', 'C:\\slave\\test\\build\\symbols', '--plugins-path', 'C:\\slave\\test\\build\\application\\thunderbird\\plugins', '--testing-modules-dir', 'C:\\slave\\test\\build\\test\\modules'] 13:07:54 INFO - Using profile dir: C:\slave\test\build\tests\mozmill\mozmillprofile 13:07:54 INFO - [1244] WARNING: Failed to load startupcache file correctly, removing!: file c:/builds/moz2_slave/tb-try-c-cen-w32-d-00000000000/build/mozilla/startupcache/StartupCache.cpp, line 219 13:07:54 INFO - (debug) nsWindowWatcher::SetWindowCreator(nsIWindowCreator* aCreator) called 13:07:54 INFO - [1244] WARNING: CheckLinkStatus called on main thread! No check performed. Assuming link is up, status is unknown.: file c:/builds/moz2_slave/tb-try-c-cen-w32-d-00000000000/build/mozilla/netwerk/system/win32/nsNotifyAddrListener.cpp, line 707 13:07:54 INFO - [1244] WARNING: This method is lossy. Use GetCanonicalPath !: file c:/builds/moz2_slave/tb-try-c-cen-w32-d-00000000000/build/mozilla/xpcom/io/nsLocalFileWin.cpp, line 3477 13:07:56 INFO - 1474488476446 addons.xpi-utils WARN addMetadata: Add-on [e-mail] is invalid: Error: Invalid addon ID: expected addon ID [e-mail], found [e-mail] in manifest (resource://gre/modules/addons/XPIProvider.jsm -> resource://gre/modules/addons/XPIProviderUtils.js:1658:15) JS Stack trace: [e-mail]:1658:15 < [e-mail]:2018:23 < [e-mail]:3808:34 < [e-mail]:2794:25 < [e-mail]:236:12 < [e-mail]:789:5 < [e-mail]:973:9 < [e-mail]:3017:5 < [e-mail]:71:9 13:07:56 INFO - 1474488476452 addons.xpi-utils WARN Could not uninstall invalid item from locked install location 13:07:57 INFO - [1244] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80520012: file c:/builds/moz2_slave/tb-try-c-cen-w32-d-00000000000/build/mozilla/extensions/cookie/nsPermissionManager.cpp, line 2675 13:07:57 INFO - [calBackendLoader] Using icaljs backend at C:\slave\test\build\application\thunderbird\extensions\{e2fda1a4-762b-4020-b5ad-a41df1933103}\components\icaljs-manifest 13:07:57 INFO - [1244] WARNING: 'NS_FAILED(rv)', file c:/builds/moz2_slave/tb-try-c-cen-w32-d-00000000000/build/mozilla/dom/plugins/base/nsPluginHost.cpp, line 2364


OBSERVATION:

As it turns out, try-comm-central log for mozmill run of linux64 debug version also has a similar error.

So it is not windows specific.

*HOWEVER*, I don't see a similar error line on my local PC's test log.
I am testing linux64 debug version on local PC.

Something is incorrectly set up on try-comm-central?

Using DXR, I found 8 occurrences of [e-mail], and
three occurrences of [e-mail].

I suspect they should be consistently named.

TIA
cf. 3 results from the comm-central tree:
mozilla/testing/specialpowers/Makefile.in
♢7 XPI_PKGNAME = [e-mail]

mozilla/testing/testsuite-targets.mk
♢ 356 [e-mail] \

obj-x86_64-pc-linux-gnu/testing/specialpowers/Makefile
♢ 15 XPI_PKGNAME = [e-mail]


windows debug version raw log is:
https://archive.mozilla.org/pub/thunderbird/try-builds/[e-mail]-8fa70f3401d6/try-comm-central-win32-debug/try-comm-central_win7_ix-debug_test-mozmill-bm126-tests1-windows-build3.txt.gz

https://treeherder.mozilla.org/logviewer.html#?job_id=21663&repo=try-comm-central

Comment 1

[ISHIKAWA, Chiaki]

--
Then Mark Banner followed it up on the same mailing list:
Looks like this is different from what is specified in
testing/specialpowers/install.rdf - which is the dashed version, and was
introduced when it was rewritten last year.

The simplest thing is probably to change the install.rdf to remove the
dash as then it wouldn't be changing the file name on disk - and also
update the other couple of instances in the tree. Probably worth a
running through a few tests on try just to make sure as well.

The test infrastructure has probably got away with it due to the next
warning of "Could not uninstall invalid item from locked install
location", so it kept on using it. 
---

My response after a run:
---
By changing a few install.rdf as suggested, the particular error messages
are gone, but
I now see different failures.

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

I am testing other patches as well, the particular patch to modify
install.rdf is
https://hg.mozilla.org/try-comm-central/rev/a135ec33cb11

I will investigate more to see if the new errors are due to my changes or
a regression caused by a later change to M-C, etc. 
---

After a few posts: Mark Banner
---

> The new errors are obviously related to my change.
...

> inline void
> CrashIfNotInAutomation()
> {
>     MOZ_RELEASE_ASSERT(IsInAutomation());
> }
>
> So where is CrashIfNotInAutomation() called?

Did you look at the IsInAutomation() function?

https://dxr.mozilla.org/mozilla-central/rev/f0e6cc6360213ba21fd98c887b55fce5c680df68/js/xpconnect/src/xpcpublic.h#606

That's clearly checking a preference that is expected for automation.
Looking at the tree, it gets set to true for most (probably all) of the
tests that Firefox runs:

https://dxr.mozilla.org/mozilla-central/search?q=security.turn_off_all_security_so_that_viruses_can_take_over_this_computer&redirect=false

This probably means that the Thunderbird specific MozMill builders
should either not be installing the special powers add-on (which I
suspect is hard), or they should also be setting the pref to true.

> I changed only these:

There's no need to include a full diff when you've already linked to it. 
---

finally
---


I thin I will set the pref to true and test the try-comm-central again.

>> I changed only these:
>
> There's no need to include a full diff when you've already linked to it.
>

Right. I will create a bugzilla to discuss this.

> Mark.

Thank you again.

---

So here I am.

Problem:

It looks that |make mozmill| seems to use an instance of its own profile when it executes the
test. Quite understandable.
However, as I looked around and modified possible candidates of such a profile to set the
mentioned preference
to true, I still see the error/warning.

So far I have modified C-C mail/test/mozmill/startup-firstrun/prefs.js

Should I modify other possible prefs.js or fragments?

cf.
mail/test/mozmill/startup-firstrun/prefs.js 		

--- a/mail/test/mozmill/startup-firstrun/prefs.js
+++ b/mail/test/mozmill/startup-firstrun/prefs.js
@@ -1,1 +1,2 @@
 pref("mail.provider.enabled", false);
+pref("security.turn_off_all_security_so_that_viruses_can_take_over_this_computer", true);