Per the author’s website, he will be doing this with all his themes: http://www.virtusdesigns.net/

This should never happen with themes hosted at AMO.

See Bug 502479

Separate JavaScript sandbox for every addon… ROTFL. I don’t want think about performance of that solution. Maybe… 10x slower?

And… Has anyone know that extensions could use XPCOM Compontents? That components can be written in C++ and compiled to native code. It’s impossible to trace and block native code in Firefox, in user-mode. Every XPCOM component can do everything, and this can’t be changed.

If you want control native code, you must create thousands hooks into operating system, and work in kernel mode. Obviously, internet browser shouldn’t do that…

What if user have some pref set to A, plugin changes it to B and some time later, user changes it to C. Should the plugin revert it back to A? If “that pref” is homepage for example, I think user will be quite unhappy with it.

I think the plugin should restore the settings to its previous values ONLY if they are not changed between installation and uninstallation of the plugin.

Perhaps add some helper functions which extension authors would call and they will do this “properly”.

“Changes to default home page and search preferences, as well as settings of other installed add-ons, must be related to the core functionality of the add-on.”

This says to me that if an add-on is not explicitly related to search (like Yahoo or Google toolbar), it can’t change search preferences, even if it is upfront with the user about the fact that it is going to change these things.

So an addon that says “we change the search engine to Foo. Please use Foo and support us” won’t be allowed to do that anymore unless the addon is explicitly related to search.

Is that correct?

(1) Enact and enforce a policy regarding scope of authority for add-ons
(2) Implement an improved process for installing (and uninstalling) add-ons
(3) Implement the functionality of the best of the best of the add-ons into the core functionality of Firefox

JR, summed up what this policy is about.

“…policy change is important and necessary to retain the trust users have in Mozilla”

If an extension isn’t upfront about the fact that it is going to change the search engine, or it takes the introduction of lots of complicated UI with lots of misunderstood or confusing words and dialogs to do so then we simple are in a race to the bottom.

When addons start to change preferences outside the core functionally of the addon, users will lose trust individual addon, then addons as a whole, then Firefox, then Mozilla. As we have seen the war can also escalate to a race to the bottom between competing addons wanting to control preferences.

We can’t put users in the middle of this battle and expect any kind of good outcome.

You are right that addon developers are caught in difficult place with no few monitization options right now and we need to solve that problem, but lets not do it at the expense of degrading user experience and trust.

Not fine.

How is this technically done? Will each plugin author need to write his own code for this, or can he use something “central”?