1528489 - Menu On Top (SuperMenu Avatar) crashes Daily @ nsComponentManagerImpl::AddBootstrappedManifestLocation

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Mark Barnes [:WoofGrrrr]]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

Launch it

I tried using both the automatic update from the previous version of Daily itself and the latest build from https://archive.mozilla.org/pub/thunderbird/nightly/latest-comm-central/

NOTE that the latest Daily build was 2019-02-11 and it's now 2019-02-16

Actual results:

Crashed, even after restart from crash dialog

Expected results:

It shouldn't crash

Comment 1

[Mark Barnes [:WoofGrrrr]]

I uninstalled this build, downloaded and installed two previous builds (2019-02-10 and 2910-02-09) and NEITHER of them will start. They report some unknown element in XUL or something like that. I'm not a TBird developer (I don't program in the language TBird is written in) so I give up.

I have reported many times before the problem that DAILY builds just stop happening, and I'm just not doing it any more. That last build was FIVE days ago.

No more DAILY for me.

Comment 2

[Wayne Mery (:wsmwk)]

(In reply to Mark Barnes from comment #1)

No more DAILY for me.

Daily channel is by definition both potentially unpredictable in various ways and unstable, even though normally on most days it is pretty decent. And yes, sometimes it doesn't update daily - things break. I hope no one told you to expect otherwise. If you are looking for something more current than a normal release but still stable, consider using beta https://www.thunderbird.net/en-US/channel/ And if you don't want to be risking your data at all, you shouldn't even be using beta.

Are these yours?
bp-97174a20-b781-459b-841d-350d50190216 This has been going on for DAYS!!! This is the latest (11-Feb-2019) build from: https://archive.mozilla.org/pub/thunderbird/nightly/latest-comm-central/
bp-79cf0e86-0027-4db6-917d-140cd0190216 Daily won't even start up!!!

bp-97174a20-b781-459b-841d-350d50190216
0 xul.dll nsComponentManagerImpl::AddBootstrappedManifestLocation(nsIFile*) xpcom/components/nsComponentManager.cpp:1966
1 xul.dll XPTC__InvokebyIndex

Comment 3

[Jorg K (CEST = GMT+2)]

Daily of 11th Feb 2019 should have been OK, see:
https://treeherder.mozilla.org/#/jobs?repo=comm-central&revision=5fa6fd01e5553af4b5057829ee4de26eec271ae7

After that, Dailies have been suspended.

Richard, the Daily from that date works, no? Geoff, what is nsComponentManagerImpl::AddBootstrappedManifestLocation ?

Comment 4

[Richard Marti (:Paenglab)]

Yes, I'm using Daily from 11. without crash.

Comment 5

[Geoff Lankow (:darktrojan) [PTO, back 28/4]]

That's what registers the chrome.manifest in a bootstrapped extension. That crash report has a bootstrapped extension. I wonder if having a packed extension causes this. Will look in to it.

Comment 6

[Geoff Lankow (:darktrojan) [PTO, back 28/4]]

Yeah, I installed the extension, and it crashed. I think that's good evidence.

Comment 7

[Geoff Lankow (:darktrojan) [PTO, back 28/4]]

Also, that extension calls Components.manager.addBootstrappedManifestLocation(data.installPath) in the install method itself. Why?

Comment 8

[Geoff Lankow (:darktrojan) [PTO, back 28/4]]

Okay, I'm now certain this is called caused by the extension's install method. data.installPath is undefined these days, so that is what's crashing.

Comment 9

[Geoff Lankow (:darktrojan) [PTO, back 28/4]]

Attachment: 1528489-manifest-failure-1.diff

For good measure, I'll prevent the crash too.

Comment 10

[Wayne Mery (:wsmwk)]

Do we have a crash ID and/or crash signature?

Comment 11

[Axel Grude]

(In reply to Geoff Lankow (:darktrojan) from comment #7)

Also, that extension calls Components.manager.addBootstrappedManifestLocation(data.installPath) in the install method itself. Why?

Most likely I copied this of another bootstrapped / example extension. All my other extensions are "classic" and need restarting, so I am not an export with restartless Add-ons at all. Is there an updated skeleton Add-on I could look at on how it is done correctly?

Comment 12

[Axel Grude]

(In reply to Axel Grude from comment #11)

(In reply to Geoff Lankow (:darktrojan) from comment #7)

Also, that extension calls Components.manager.addBootstrappedManifestLocation(data.installPath) in the install method itself. Why?

Most likely I copied this of another bootstrapped / example extension. All my other extensions are "classic" and need restarting, so I am not an export with restartless Add-ons at all. Is there an updated skeleton Add-on I could look at on how it is done correctly?

Looking at this reference here:
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIComponentManager#addBootstrappedManifestLocation()

I most likely included it because my Add-on contains XUL overlays (and a XUL dialog for configuration). I didn't want to shoehorn in a content tab and all the complication of communication with that layer from the chrome / privileged layer, and xul is still the easiest way to build a nice, functional, non-modal configuration dialog.

Is it possible to debug the line with Developer tools? I could just wrap it in a try..catch if it doesn't do anything on modern XUL platforms.

Comment 13

[Axel Grude]

Attachment: 1.11 Prerelease 3

Here is a quick fix only running the line if data.installPath is set and also logs the exception on install if there is a problem. works for me with Thunderbird 64.0b1 (32-bit) in Windows 7

Comment 14

[Axel Grude]

Attachment: 1.11 prerelease 15

I fixed a few compatibility issues (including the toolbar button and the remove functionality on advanced / bookmarks)

Only known issue is that my groupbox XUL elements are not visible now, so we are missing a bit of context for some of the options in the preferences dialog. Not sure whether groupbox was deprecated or I neeed some additional rule. Apart from that it seems to behave well in Tb 60.0b1

Will update the official version at ATN soon, just want to do some testing on Waterfox first.

Comment 15

[Geoff Lankow (:darktrojan) [PTO, back 28/4]]

I don't think you're still supporting Firefox 9, so you don't need to call that function at all. :-)

Comment 16

[Kris Maglione [:kmag]]

Comment on attachment 9044743 [details] [diff] [review]
1528489-manifest-failure-1.diff

Review of attachment 9044743 [details] [diff] [review]:
-----------------------------------------------------------------

::: xpcom/components/nsComponentManager.cpp
@@ +1966,5 @@
>  
>  NS_IMETHODIMP
>  nsComponentManagerImpl::AddBootstrappedManifestLocation(nsIFile* aLocation) {
> +  if (!aLocation) {
> +    return NS_ERROR_FAILURE;

NS_ENSURE_ARG_POINTER(aLocation), please.

@@ +1987,5 @@
>  
>  NS_IMETHODIMP
>  nsComponentManagerImpl::RemoveBootstrappedManifestLocation(nsIFile* aLocation) {
> +  if (!aLocation) {
> +    return NS_ERROR_FAILURE;

Here too.

r=me with that.

Comment 17

[Geoff Lankow (:darktrojan) [PTO, back 28/4]]

Attachment: 1528489-manifest-failure-2.diff

Comment 18

[Geoff Lankow (:darktrojan) [PTO, back 28/4]]

Not sure this is really Toolkit::Add-Ons Manager, but it won't be seen for check-in if it remains in Thunderbird.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/810c452f755a
Return failure code instead of crashing in Add/RemoveBootstrappedManifestLocation; r=kmag

Comment 20

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/810c452f755a