Revisiting how we build Firefox

Gijs Kruitbosch gijskruitbosch at gmail.com
Sat Jul 11 08:52:35 UTC 2015


On 10/07/2015 23:08, Chris Hofmann wrote:
> On Fri, Jul 10, 2015 at 2:42 PM, Robert Kaiser <kairo at kairo.at 
> <mailto:kairo at kairo.at>> wrote:
>
> > I personally wonder how this fits at all into the three pillars of 
> Firefox development that were presented
> > recently, and where the direct user benefit is in "killing XUL". 
> That said, XUL was created as a transitional
> > technology because HTML wasn't ready for UI (and it still isn't 
> fully there yet, even though much further along)
>
>
> Yes that's a good topic to get conversation and investigation 
> started.  I might be missing something but as far as I can see it does 
> have a major contribution to any of the 3 pillars, and in several 
> places maybe in direct conflict with plans around the 3 pillars.
>
> Shipping features as Addons and increasing our dependence on Addons is 
> one example.  If we change the UI framework we would be needing to 
> create a whole new extension, packaging and installation system for 
> addons right at a time we would be becoming more reliant on addons, 
> and would also need to figure mechanism to transition current addons 
> to what ever this new addon system might be.  We would also need to be 
> creating something that replaces overlays to UI content areas either 
> in HTML or create multiple ways of doing this on each of the native 
> platforms.
Work is ongoing on improving our add-on API system, "killing" XUL there.
> We would also need to transition localization systems and tools, and 
> other things that XUL provides for now.

I disagree with you that XUL as a UI language and layout module is used 
for localization. It isn't. Our l10n infrastructure is used from XUL, 
because we happen to use XUL for our UI, but the DTD and properties 
files that store the actual l10n data, as well as the XPCOM interfaces 
that provide access to them, are perfectly usable from elsewhere (and we 
do use them from (X)HTML/JS in certain cases).

The list you provided in your other post:

 > Overlays, Themes, Addons, Packaging, Installation, Localization, etc...

is actually quite short, given the above. I don't know what you mean by 
packaging and installation - our installer doesn't use XUL, I believe, 
and the packaging into jar files (just with HTML/JS under content/ 
instead of XUL/JS) could be kept if we wanted.

And as David said, nobody is saying "let's just chuck it all out 
tomorrow without thinking about how to build a browser without them". 
But we are saying it's an area where we've invested less, and not just 
less but an order of magnitude (or two or three) less than in HTML, nor 
is it part of our core mission, and it is actively impeding some of the 
work we're doing.

Examples of issues I can remember off the top of my head:
1) adding a single button to the toolbar of the main Firefox UI slows 
down startup and new window openings (talos!) by a few milliseconds 
spent in XUL layout / XBL construction alone.
2) XBL bindings that get removed at "odd"/unexpected times cause 
intermittent bugs
3) XUL flexbox + "new" flexbox mix badly together
4) panel and popup layout is "interesting" and causes serious bugs (cf. 
https://bugzilla.mozilla.org/show_bug.cgi?id=1029937 )
5) XBL interacting weirdly with new CSS features (cf. 
https://bugzilla.mozilla.org/show_bug.cgi?id=1093260, quote from bz: 
"Welcome to XBL sucking.")
6) adopting "webby" toolkits like react/jquery/... (the Loop team is in 
a better position to talk about this than I am)

and the list goes on.

The status quo is not acceptable, and I haven't even started on how the 
technology gap hampers new contributors.

~ Gijs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20150711/35d8dc5f/attachment.html>


More information about the firefox-dev mailing list