Confusion about 'module' imports

[thosrtanner]

So I have an extension that includes a module which provides wrappers for alert, prompt and confirm which stick the name of my extension in the title bar. Because, well, I'm lazy and I find boxes coming up without any hint as to where they came from are rather worrying.

The code (from infoRSS) starts off like this:

Code: Select all

/* exported EXPORTED_SYMBOLS */
var EXPORTED_SYMBOLS = [
    "alert", /* exported alert */
    "prompt", /* exported prompt */
    "confirm", /* exported confirm */
];

function alert(msg)
{
    promptService.alert(null, inforssGetName(), msg);
}

and it seemed to work fine.

Today I installed s3.translator so I could see what I was filling in on that Japanese survey.

And all its prompts came up with an inforss prefix.

So what context are extensions run in? Is it a huge global one, where any function name can mess with any other extension? And if so, how the heck is one meant to protect against conflicts?

[JustOff]

Overlay extensions (the ones that use chrome.manifest to extend existing XUL files) share common namespace so their developers must take special measures to avoid conflicts with the browser code and other add-ons. Obviously, infoRSS does not do this well.

PS: Restartless extensions (including Add-on SDK based) run in their own scope and do not have this problem.

[New Tobin Paradigm]

Bootstrap extensions also have some drawbacks as well.. Kinda depends on what you are ultimately wanting to do i suppose..

[thosrtanner]

I keep shying off making this restartless because the documentation is a bit "don't do this" + handwavy magic about how to get round it. But the first thing it says is that one of the issues is fixed by this: https://bugzilla.mozilla.org/show_bug.cgi?id=675372 which went into firestorm 38. Which is a bit after palemoon first forked. So does palemoon have that fix?

[JustOff]

Yes, bug #675372 is the part of the Pale Moon 27 codebase. However, in most cases you can safely use the chrome:// protocol instead of the resource:// like it did before this bug was implemented.