275054 - installing two different extensions with the same chrome name doesn't display an error message, but only second one works

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, defect)

Description

[Roman J. Mashirov]

Description:
No error message displayed when installing two extensions, sharing the same
short name, and installation is not blocked. As a result extensions.rdf and
chrome.rdf contains some strange mixt of both extensions and FF freezes when
started with following message:

*** loading the extensions datasource
*** nsExtensionManager::start - (safe mode) failure, catching exception so
finalize window can close
*** Failed to load overlay chrome://outliner/content/outlinerOverlay.xul

-safe-mode does not solved problem for me (FF still frozen), but it been
reported that it allows to uninstall one of conflicting extensions (different
configuration?).

To reproduce:
1) BACKUP FF PROFILE, IT WILL BE CORRUPTED
2) Install both attached extensions (in one step or in two -- does not matter)
3) After FF restarted it will freeze

Comment 1

[Roman J. Mashirov]

Attachment: First of two extensions to reproduce the bug

Comment 2

[Roman J. Mashirov]

Attachment: Second extension to reproduce the bug

Comment 3

[Nickolay_Ponomarev]

Confirmed the freeze for me. I started with a clean profile, installed the first
extension, restarted, installed the second extension. Safe mode worked correctly.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Comment 4

[Przemyslaw Bialik]

On latest trunk installing both of these extensions does not freeze FF but only
extension which was installed as a second one has entries in View->Sidebar /
Tools menu.
To make them reappear for the first extension, extension which was the last one
installed has to be uninstalled / disabled.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050327
Firefox/1.0+

Comment 5

[Nickolay_Ponomarev]

Same as in comment 4 here, changing summary, removing hang keyword, lowering
severity.

Comment 6

[Przemyslaw Bialik]

What are your ideas to fix this bug ?
- forcing chrome name = <em:id> is rather not an option...
- maybe disallow the installation of extension if extension with such chrome
name is already installed and their ID's are not the same ? (this would not fix
the bug as many would like [allow the proper work of such extensions] but it
would prevent it from happening)

BTW not so long ago I've found second set of conflicting extensions:
Split_Screen_1.0.xpi and splitscreen_2005.04.27.xpi .

Comment 7

[Benjamin Smedberg]

Does this problem still happen in Firefox 1.5 release candidates?

Comment 8

[Przemyslaw Bialik]

(In reply to comment #7)
Yes.
FYI I've got more real life examples:
- QuickPrefs_1.0.1u_rep.xpi & Quick_Preference_Button_0.1.xpi
- QuickFile_0.0.3.xpi & Quick_File_0.15.xpi

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051117 Firefox/1.5

Comment 9

[Benjamin Smedberg]

ok, there are separate problems here:

1) two extensions use the same chrome package name (i.e. chrome://quickfile/). This is not something that we really have the ability to fix; like other global-namespace conflicts you should just try to choose unique names.

2) the extensions.rdf file or other metadata gets messed up when two extensions from situation 1) get installed at the same time: this is more serious and we should try to fix it if possible

Comment 10

[Przemyslaw Bialik]

(In reply to comment #9)
> 1) two extensions use the same chrome package name
two or more ;)

> like other global-namespace conflicts you should just try to choose unique
> names.
for chrome package names devs are using mostly (shortened) <em:name>, they might think the name is unique (if caring at all) but many times they just aren't bothered to search well for similar extension (which has same chrome name) or they are but they didn't find it and as a result we have this bug and these examples...

Comment 11

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

Maxx - can you provide links to the extensions you reference in comment #7 ?

re: global namespace - just as ext dev's had to learn that they have to b careful with function names in the global namespace they also have to be careful with the chrome package name.

re: corrupted metadata - definitely something that should be fixed if possible.

Comment 12

[Przemyslaw Bialik]

(In reply to comment #11)
> Maxx - can you provide links to the extensions you reference in comment #7 ?
you wanted to say #6 and #8 ? ;)

- <a href="http://www.extensionsmirror.nl/index.php?showtopic=3036>Split_Screen_1.0.xpi</a>
- splitscreen_2005.04.27.xpi was renamed to <a href="http://www.extensionsmirror.nl/index.php?showtopic=3299>twoview - The Extensions Mirror</a>
- <a href="http://www.extensionsmirror.nl/index.php?showtopic=90>QuickPrefs_1.0.1u_rep.xpi</a>
- Quick_Preference_Button_0.1.xpi -> <a href="http://www.extensionsmirror.nl/index.php?showtopic=4369>Quick Preference Button 0.0.5 - The Extensions Mirror</a> (fixed chrome name)
- <a href="http://www.paultomlin.com/projects/mozilla/thunderbird/quickfile/">Quick_File_0.15.xpi</a>
- <a href="http://yergler.net/projects/quickfile/releases/">QuickFile_0.0.3.xpi</a> (no longer maintained)

Looks like 2 original (chrome conflicting) versions are no longer available on the net, if you want I can attach them to the bug ? though 2 existing attachments should be rather enough for this bug.

Comment 13

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

I don't need them - I wanted to see if they were copy paste errors which these types of errors usually are. I look at these sort of global namespace mistakes in the same light as copying code and using the same function names or the same id's in the DOM both of which I have seen more often than this issue... IMO the answer is to improve awareness of this to extension developers.

Comment 14

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

Works for me with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0a1) Gecko/20110430 Firefox/6.0a1

Can we close this out or is someone still able to see that issue?

Comment 15

[Dave Townsend [:mossop]]

This will still be a problem. I think I'm going to say that we shouldn't spend time trying to solve this, it is basically similar to two extensions using the same variable name in browser.js, just conflicting extensions.

We've talked for a while about allowing AMO to track known incompatible extensions (bug 621404), I'd probably want to use that in preference to any specific fix here.