284188 - Corrupt extension install.rdfs cause an infinite loop on startup

Status: RESOLVED WORKSFORME

(Toolkit :: Startup and Profile System, defect)

Description

[Jim Ginn]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050227 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050227 Firefox/1.0+

When starting Firefox with an old profile, it is possible to trap Firefox in an
endless loop of "corrupt install.rdf" alert messages - if the profile contains
an extension with a corrupt install.rdf file. I initially triggered this bug
using the latest stable version of the googlebar extension (the latest
experimental version has been fixed).

Reproducible: Always

Steps to Reproduce:
1.Install an older trunk build (before 2/17).
2.Install an extension with an invalid install.rdf (such as the googlebar
version 0.9.0.30 extension).
3.Update Firefox to the most recent nightly.
4.Attempt to start Firefox.

Actual Results:  
Firefox will not start and is stuck in an endless loop of "corrupt install.rdf"
error messages.

Expected Results:  
Firefox alerts the user to the corrupt install.rdf file and disables the
offending extension.

I think this might be a regression from Bug 278534. I was able to workaround the
problem by loading Firefox in safe mode and disabling googlebar.

Comment 1

[Jim Ginn]

The extension StumbleUpon also will cause the infinite error loop.

Comment 2

[James Ross]

I found the infinite-restart loop also happens if extensions/Extensions.rdf has
a bad entry, such as this one created by the EM in a previous life:

<RDF:Description
    RDF:about="urn:mozilla:extension:m/~ginda/chatzilla/xpi/chatzilla-0.9.64f.xpi"
    NS2:toBeUninstalled="true" />

which caused the following spew prior to each restart:

*** loading the extension datasource
*** getItemProperty failing for lack of an item. This means getResourceForItem
failed to locate a resource for aItemID (item ID =
m/~ginda/chatzilla/xpi/chatzilla-0.9.64f.xpi, property = installLocation)
*** nsExtensionManager::_finishOperations - failure, catching exception so
finalize window can close [Exception... "Component returned failure code:
0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH) [nsIFile.append]"  nsresult:
"0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH)"  location: "JS frame ::
file:///C:/DOCUME~1/James/MYDOCU~1/Mozilla.org/DEVELO~1/TREE-F~1/objdir/dist/bin/components/nsExtensionManager.js
:: getDirInternal :: line 145"  data: no]

Comment 3

[Jim Ginn]

I forgot to mention this, but the reason googlebar and stumbleupon cause the
loop is because they use an invalid namespace,

<RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
     xmlns:em="http://www.mozilla.org/2004/em-rdf#">

instead of

<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
     xmlns:em="http://www.mozilla.org/2004/em-rdf#">

Comment 4

[Benjamin Smedberg]

*** Bug 284277 has been marked as a duplicate of this bug. ***

Comment 5

[Benjamin Smedberg]

Attachment: Guard against infinite restart, rev. 1 [checked in]

This patch wallpapers over underlying code problems in the extension manager by
forcing restart to only occur once.

Comment 6

[Darin Fisher]

Comment on attachment 176143 [details] [diff] [review]
Guard against infinite restart, rev. 1 [checked in]

Doesn't this cause problems when we need to restart twice: once for profile
selection and once for EM purposes?

Comment 7

[Benjamin Smedberg]

darin, no: the EM restarting recursion check takes place after profile selection
is all done.

Comment 8

[Darin Fisher]

Comment on attachment 176143 [details] [diff] [review]
Guard against infinite restart, rev. 1 [checked in]

ok then, r=darin

Comment 9

[Benjamin Smedberg]

Comment on attachment 176143 [details] [diff] [review]
Guard against infinite restart, rev. 1 [checked in]

Recursion guard is checked in. I'm leaving this bug open to fix the EM
exceptions.

Comment 10

[Ben Goodger (use ben at mozilla dot org for email)]

sounds like this is fixed. 

Comment 11

[Benjamin Smedberg]

The "real bug" isn't fixed yet.

Comment 12

[Benjamin Smedberg]

I suspect this is significantly improved with the new extension manager. I just
want to make sure we don't get into a situation where an extension is marked
with "needs-install" permanently.

Comment 13

[John Collins]

I can confirm that with 1.0.5, a MISSING [installdir]\extensions\extensions.rdf
file will result in an infinite loop... cant the browser, in that circumstance,
simply generate a "safe" extensions.rdf file to fix the problem? once that file
is replaced, the loop ends.

Comment 14

[John Collins]

Sorry for double post, forgot to add, this only occurs during profile creation,
ie on first run.

Comment 15

[Benjamin Smedberg]

I can't get this to happen any more with the new 1.5 EM changes.