Living in a Go Faster, post-XUL world

Quicksaver quicksaver at gmail.com
Wed Jul 15 12:10:43 UTC 2015


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



More information about the firefox-dev mailing list