1334848 - Fatal exception in Addon Manager (addons.xpi)

Status: RESOLVED WONTFIX

(WebExtensions :: General, defect)

Description

[rmenessec]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170123004004

Steps to reproduce:

Test systems: Ubuntu Linux 16.04 amd64.

Started Firefox 53.0a2 (Aurora) with addons registered in profile. Tested with several working profiles that have not caused problems with Firefox 45.x-52.x (testing profile #1, minimal addons), Firefox 45.x-52.x (testing profile #2, 100+ addons, rarely used), and Firefox 6.x-52.x (working profile).

To clarify: my working profile is not corrupt. Reverting to a 52.0a2 build works correctly. Restoring a backup of my working profile folder from Firefox 47.0a2 works correctly with Firefox 52.0a2, but not 53.0a2.

Starting Firefox 53.0a2 in safe mode works, but 53.0a2 does not appear to work with addons, or at least with some / most / many addons. Disabling addons at random (using 52.0a2) does not vary results.

I maintain two rarely-used testing profiles that are incompatible with 53.0a2: a profile with minimal addons (Cookie Controller, Ghostery, LastPass, NoScript, StartupMaster, uBlock Origin) and a profile with these and about a hundred more randomly selected addons, including both classic and JetPack addons.)


Actual results:

TypeError: AddonManagerInternal._getProviderByName(...) is undefined

Extension error: AddonManagerInternal._getProviderByName(...) is undefined resource://gre/modules/AddonManager.jsm:2373 :: getAddonByInstanceID@resource://gre/modules/AddonManager.jsm:2373:13


Expected results:

Firefox finishes loading addons and draws UI.

I don't believe that even malformed or corrupt extensions should be able to crash Firefox' Addon Manager, or Firefox in general.

Comment 1

[rmenessec]

Attachment: missing EOLs (obsoleted)

Comment 2

[rmenessec]

Comment on attachment 8831491 [details]
missing EOLs (obsoleted)

.

Comment 3

[rmenessec]

Attachment: Console output

Comment 4

[rmenessec]

UPDATE: The Addon Manager appears to have crashed because StartupMaster ( https://addons.mozilla.org/en-US/firefox/addon/startupmaster/ ) was active across all of my active and testing profiles. I assume it's because StartupMaster delays loading the entire Firefox browser until the NSS credentials are unlocked ( Firefox Master Password: about:preferences#security )

This appears to be a bug in the Addon Manager rather than in StartupMaster; I would guess that Addon Manager contains a race condition or similar flaw.

I'm reaching out to the StartupMaster project owner for guidance.

Comment 5

[Andrew Swan [:aswan]]

(In reply to rmenessec from comment #0)
> I don't believe that even malformed or corrupt extensions should be able to
> crash Firefox' Addon Manager, or Firefox in general.

Neither do we!  But trying to deal with this is a very large and ongoing effort.

In the mean time, I'm unable to reproduce this, since it appears to be a recent regression, can you narrow down the source with mozregression?  (http://mozilla.github.io/mozregression/quickstart.html)

Comment 6

[rmenessec]

(In reply to Andrew Swan [:aswan] from comment #5)
> (In reply to rmenessec from comment #0)
> > I don't believe that even malformed or corrupt extensions should be able to
> > crash Firefox' Addon Manager, or Firefox in general.
> 
> Neither do we!  But trying to deal with this is a very large and ongoing
> effort.
> 
> In the mean time, I'm unable to reproduce this, since it appears to be a
> recent regression, can you narrow down the source with mozregression? 
> (http://mozilla.github.io/mozregression/quickstart.html)

I probably can't. I use only Aurora builds, so the bug could have been introduced any time before 53.x was promoted to Aurora. From the look of mozregression, it would require manual testing of anywhere up to... what, half of all the 53.x builds? :/

I simply can't afford the time to do that right now; probably not for a few weeks, if then.

For the moment, all I can confirm is that the very first linux-x86_64 53.x build to end up in https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora/ had the flaw. No build of Firefox before then - going back years - had this flaw. (Or, if this is more complex, this particular combination of problems didn't surface until now.)

...In case that requires amplification: I have a dedicated bash script that pulls the latest latest-mozilla-aurora/$MOZMAJOR.0a2 tarball daily, or else the latest $(MOZMAJOR + 1).0a2 tarball, if one exists. I'd be using betas, if the betas had a way to disable extension signing requirements...

Comment 7

[rmenessec]

(In reply to Andrew Swan [:aswan] from comment #5)
> (In reply to rmenessec from comment #0)
> > I don't believe that even malformed or corrupt extensions should be able to
> > crash Firefox' Addon Manager, or Firefox in general.
> 
> Neither do we!  But trying to deal with this is a very large and ongoing
> effort.
> 
> In the mean time, I'm unable to reproduce this, since it appears to be a
> recent regression, can you narrow down the source with mozregression? 
> (http://mozilla.github.io/mozregression/quickstart.html)

Clarification: mozregression mentions clean profiles. The bug is only reproducible with StartupMaster installed and enabled, so far as I can tell. It might require having several or many other extensions installed - say, in order to produce a sufficient delay in completing intialization of Addons Manager.

_If_ mozregression keeps my testing and working profiles safe and out of the way, that would help. Do you have any automated means of applying extensions during use of mozregression?

My first answer is conditional on the fact that I don't have any kind of automated testing framework at all that would handle backing up / moving profiles, automatically installing extensions, etc. I don't have anything like a QA environment, in short; and I don't have time to build one out unless it's a matter of installing a few tools in an isolated directory...

Comment 8

[Loic]

mozregression has a lot of options, type "mozregression --help".
You can specify a testing profile with mozregression --profile=/PATH

Just create a fresh profile, install the add-on and start mozregression with this profile and the command --profile-persistence=reuse.

Comment 9

[Andrew Swan [:aswan]]

Well I can't reproduce this, I think the bug is in Startup Master.  The fact that it worked previously doesn't really change that.  But if somebody who can reproduce this can provide a narrower regression range, perhaps we can provide more help.

Comment 10

[Loic]

I tried Nighly with the add-on installed, I can't reproduce the crash.

Do you have clear STRs?

In the add-on options, I checked only "Delay password prompt...". Then I set a master pwd but I didn't get a crash when opening the list of pwds saved in Firefox.

Comment 11

[Jorge Villalobos [:jorgev] (he/him)]

Mass-closing bugs that relate to legacy versions of add-ons or are otherwise no longer worth tracking. Please comment if you think this bug should be reopened.

Sorry for the bugspam. Made you look, though!