291872 - Registering an extension by placing a file, with a name different from extension's GUID, in extensions\ doesn't work but it takes Firefox two restarts to figure it out

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Nickolay_Ponomarev]

This is a bug in feature introduced in bug 286034.

Creating a {GUID1} file pointing to C:\extension with guid={GUID2} creates a
{GUID2} subdirectory in profile\extensions\ and messes up Firefox

GUID1={3f0da09b-c1ab-40c5-8d7f-53f475ac3fe8}
GUID2={71e95839-6f7e-470d-be54-77012fec6313}

I get a two alerts on each startup (about absent install.rdf) and the following
messages in the JS console. First startup has an additional "Failure in Chrome
Registration" alert between the two alerts about install.rdf. A folder with
{GUID2} name is created in profile\extensions\. Uninstall doesn't work.

Item Installed via directory addition to Install Location: app-profile Item ID:
{3f0da09b-c1ab-40c5-8d7f-53f475ac3fe8}, attempting to register...

Item Installed/Upgraded at Install Location: app-profile Item ID:
{3f0da09b-c1ab-40c5-8d7f-53f475ac3fe8}, attempting to register...

... success, item is compatible

Installer::install: metadata datasource for extension
{71e95839-6f7e-470d-be54-77012fec6313} at C:\Documents and
Settings\Коля\Application
Data\Mozilla\Firefox\Profiles\p763f7tq.em-test\extensions\{71e95839-6f7e-470d-be54-77012fec6313}\install.rdf
could not be loaded.  Installation will not proceed.

ExtensionManager:_finishOperations - failure, catching exception... TypeError:
installManifest has no properties

extensions-startup.manifest is stuck with this line:
app-profile	{71e95839-6f7e-470d-be54-77012fec6313}
extensions/{71e95839-6f7e-470d-be54-77012fec6313}	1114463669	needs-install

Comment 1

[Benjamin Smedberg]

Yes this sucks, we should check the install.rdf and prevent registration in this case (same thing happens if you add an extension directly and the directory name doesn't match the install.rdf name).

Comment 2

[Nickolay_Ponomarev]

It's better now (recent trunk build), I see the following messages at the first startup:

Item Installed via directory addition to Install Location: app-profile Item ID: a@d.c, attempting to register...
Item Installed/Upgraded at Install Location: app-profile Item ID: a@d.c, attempting to register...
... success, item installed but is not compatible

Error: installLocation has no properties
Source File: file:///J:/mozilla/firefox/dist/bin/components/nsExtensionManager.js
Line: 2035

- after that the extension appears in the EM window with status "will be installed after a restart". After a restart, it gets 'uninstalled', but its entry in extensions.cache is still there, so EM doesn't try to re-register it at subsequent startups.

Comment 3

[Adam Guthrie]

Dupe of bug 352847?

Comment 4

[Robert Strong (they/them - no direct email)]

nope, this is different than bug 352847.

Comment 5

[Dave Townsend [:mossop]]

This is fixed with the extension manager rewrite

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; en-US; rv:2.0b2pre) Gecko/20100704 Minefield/4.0b2pre

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Dave, I would say it's not possible to test with an automated test, right? In that case I would simply create a Mozmill test instead of having a Litmus test.

Comment 8

[Dave Townsend [:mossop]]

Should be possible to do automatically, I think it might already be there but I need to verify that.

Comment 9

[Dave Townsend [:mossop]]

This already has a test in test_filepointer.js