Revisiting how we build Firefox

Chris Hofmann chofmann at
Sat Jul 11 14:50:36 UTC 2015

On Sat, Jul 11, 2015 at 1:52 AM, Gijs Kruitbosch <gijskruitbosch at>

>  On 10/07/2015 23:08, Chris Hofmann wrote:
> On Fri, Jul 10, 2015 at 2:42 PM, Robert Kaiser <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.

This kind of approach is great!  But I'd call it incremental replacement of
a component, not "killing" the big bad MF'er.

>  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).

I depends on what alternative is chosen.  This is not so easy if its native
UI's that are chosen. Then we either will be hacking some
transitional/transformational thing together, or be plugging directly into
the different  localization frameworks on the different platforms.

> 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.
> )
> 5) XBL interacting weirdly with new CSS features (cf.
>, 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.
This list is useful.  But  its a one sided evaluation of the problem since
it doesn't talk about how these problems in XUL might compare performance
wise (or be solved by?) one solution (browser.html) or the other (native
UI), or even others...  That's the next big step in a thoughtful evaluation
of which direction to head.

> The status quo is not acceptable, and I haven't even started on how the
> technology gap hampers new contributors.
how would the alternatives hamper new contributors?...    if its a native
solution that's chosen its a return to the bad old days that from which XUL
was born.   One platform races ahead at the expense of others since it
attracts all the cool developers.   Back at netscape it was a big pile of
windows developers piling on "best of the web features of the day" racing
to match Microsoft, and poor Mac and Xhead developers left struggling to
catch up.  The windows developers with poor cross platform experience
constantly breaking things on Mac and Unix as they went...    Both
tinderbox and XUL were born from the tension around these problems.

Now days is Mac's on everyone's laps but all our users are on windows.
Maybe this would force more balance but it still would tax new
contributors.  Hard to say. Or maybe your thinking browser.html is the
chosen path; but I have not heard that.  I mostly heard that "we don't know
what solution might be better, and hence part of the confusion and
awkwardness  in getting this discussion going..."


> ~ Gijs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the firefox-dev mailing list