Jason Barnabe

Problems that occur when two specific extensions are installed are difficult to debug. You often won’t see the problem yourself, it’ll be some user reporting it. You have to lasso them long enough to figure out that that indeed is what’s happening rather than some system-specific or a difficult-to-reproduce bug. Once the conflicting extension is found, you have to delve into its gooey innards and try to make some sense of it.

These problems often happen because of conflicts in naming resources in a shared space. Extension A and Extension B may both want to call something “foo”, but only one of them wins. It’s a messy situation, and it’s best to avoid it in the first place.

Here are some areas that can cause naming conflicts, and how to avoid the conflicts:

• Scripts loaded by overlays. Any script you include in an overlay will be added to the scope of the file you’re overlaying. Since most extensions overlay the Firefox browser window, this is a common area for conflicts. To resolve this problem, wrap any functions loaded in an overlay in an object that includes your extension’s name.
• Entities in DTDs loaded by overlays. Same problem as above. In this case, prefix the entity names with your extension’s name.
• IDs of elements loaded by overlays. Again, prefix with the extension’s name.
• Window and dialog names (the argument passed to window.open). These are used to do things like allowing only a single window of a specified name. Prefix!
• Preference names. A generic preference name could conflict with one that already exists. The standard seems to be to give them a name of “extensions.(extensionname).(description)

Other things don’t cause naming conflicts, and tossing prefixes and the like would just make them messy.

• File names. They will all be referenced under your extension’s chrome folder, so there is no possible conflict. Do not include your extension’s name in them.
• Scripts not loaded by overlays. Your XUL will be the only loaders of these scripts, so there’s no risk of conflicting with existing app or third-party code. Define functions in the global scope or as part of objects, whatever floats your boat.
• Entities in DTDs not loaded by overlays. Same as above.
• IDs in non-overlay XUL. Same
• Stringbundle property keys. You have to specify which stringbundle to load keys from, therefore one doesn’t affect the other.

This entry was posted Tuesday, February 6th, 2007 at 10:58 am and is filed under Extension Development. You can leave a response, or trackback from your own site.