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

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

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+

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

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 .

Does this problem still happen in Firefox 1.5 release candidates?

(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

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

(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...

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.

(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.

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.

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?

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.