Living in a Go Faster, post-XUL world

David Rajchenbach-Teller dteller at
Wed Jul 15 12:33:37 UTC 2015

I believe that the idea is that an addon with few/no privileges can be
reviewed quickly – possibly automatically, or possibly by someone with
less experience in the internals of the platform. At the moment, every
addon runs with full privileges, which contributes to making AMO
unresponsive (that and the fact that AMO is sorely understaffed).

All this is related to the post-XUL discussion insofar as we would like
the front-end of Firefox to be written with add-ons. To achieve this
goal, we need add-ons to be able to reach to the depths of Firefox, as
they currently do.


On 15/07/15 14:10, Quicksaver wrote:
> On 15-07-2015 03:51, Eric Shepherd wrote:
>> I think you can come up with a phased sandboxing solution; that is,
>> you can use a permissions-based mechanism by which code that is signed
>> and authenticated can access core Gecko stuff in ways that other code
>> cannot.
> Shouldn't this discrimination be made by the AMO reviewer team as is
> done already, by rejecting add-ons that do things they aren't supposed
> to? I fail to see how adding more layers of add-on quality control to
> the core application itself would help at all on the post-XUL world, not
> to mention it would require further man-hours into maintaining some sort
> of platform to accept/reject/include/review said "higher priviledged"
> add-ons.
> Also, and most importantly, I don't understand why this would even be
> necessary. As an outsider looking in on the process and assuming parity
> between the current XUL-based UI and the future HTML-based UI, the basic
> differences between those would be the node names and types - yes,
> that's an extremelly gross over-simplification, but I think it's valid
> from the point of view of an add-on aiming to modify the UI (these would
> be the add-ons most affected by this change?). Whatever an add-on can do
> now in XUL should also be able to do in HTML, no?
> As an add-on developer, I was enjoying this whole "drop XUL" discussion
> up until this point. This was a bit scary, it sounds like there would be
> further restrictions of what an add-on can do - unnecessarily. Unless
> this is more of a tangent to the main post-XUL discussion (i.e. add more
> privileges/abilities to add-ons)? Although it sure doesn't read like
> that...
> (PS. I'm not discriminating between XUL/Overlay-based, bootstrapped and
> JetPack/SDK add-ons. Are you? If so that really should be made more clear.)
> Luís Miguel
> _______________________________________________
> firefox-dev mailing list
> firefox-dev at

David Rajchenbach-Teller, PhD
 Performance Team, Mozilla

More information about the firefox-dev mailing list