Some context that might help people understand this email...<p>There are two high-level components which make up Firefox. The first is Gecko, the rendering engine. The second is Firefox, the application itself, which uses Gecko to render Web pages and itself.<p>Firefox, built on top of Gecko, is written primarily in XUL and XBL (and JS).<p><a href="https://en.wikipedia.org/wiki/XUL" rel="nofollow">https://en.wikipedia.org/wiki/XUL</a>
<a href="https://en.wikipedia.org/wiki/XBL" rel="nofollow">https://en.wikipedia.org/wiki/XBL</a><p>What's going on here is that Mozilla is considering getting rid of XUL and XBL and building Firefox with the same technologies that people use to build Web content.<p>There are at least three big advantages to doing this:<p>1. Eliminate the need to support XUL and XBL in Gecko.<p>2. Contributing to Firefox gets easier because there is no need to learn what are essentially Mozilla-specific languages.<p>3. Mozilla learns more about what it takes to build complex applications like Firefox itself using Web technologies.<p>The only real downside is the amount of work involved.
I hate the trend of building native UIs in HTML, because the result never feels right. For example, Firefox does not use OS X native context menus, and it shows in how they look, position themselves, animate, respond to keyboard and mouse events, etc.<p>But Firefox devs have clearly spent a great deal of effort to make these faux-context menus look native. What an enormous waste of development energy to emulate what the platform already provides!<p>Rather than pushing forward with a layer that provides even less access to platform UI elements, I wish they would recommit themselves to keeping the native elements native.
The correct thing to use is AppKit on OS X, WPF on Windows, GTK+ on Gnome, and Qt on KDE. Yes, this requires more code, but it results in a much, much better experience. As an OS X user, it's <i>so</i> obvious when an app isn't properly using AppKit.
Mozilla has been doing experiments in building browser UI in HTML for a long time. For instance, see Chromeless ( <a href="https://blog.mozilla.org/labs/2010/10/chromeless-build-your-own-browser-ui-using-html-css-js/" rel="nofollow">https://blog.mozilla.org/labs/2010/10/chromeless-build-your-...</a> ).<p>Current HTML is capable enough. It's nice to see them talking about adopting that in mainline Firefox.
It's probably time (past time, actually) for Mozilla to start looking into putting XUL/XBL to pasture for Firefox UI and using HTML/CSS/JS instead, since the Web platform has become sufficiently capable that the arguments for having a separate stack of technologies for building UI don't really hold anymore.<p>Still makes me a bit sad to see it go, though; I'm old enough to remember when XUL seemed like an exciting potential platform for general-purpose app development. Which never really panned out, alas, but was fascinating at the time.
This email represents an intention to start investigating moving away from XUL/XBL. There are a number of areas to explore here like how to properly handle L10N, add-on overlays, and where to go native vs markup. At the same time we're actively moving over to e10s (electrolysis / per process tabs). There will be followup communication about who is doing the work and what work is being done but now is the time to add your concerns and comments or offer support.
Can XUL/XBL just be ``compiled-down" to proper HTML, or is there also a security issue in that Gecko allows XUL/XBL to break rules needed to securely render HTML?
<i>> Is there space for a native-code main-window on desktop like we have on Android?</i><p>Sailfish browser did it as well (using native UI). Desktop Firefox also can benefit from IPCembedlite. But the question will be, what should be used to write the UI. Qt as well?<p>I'm a bit torn on that, since switching away from "Webby" interface basically killed Fennec for Meego, and only Android started getting UI improvements (that's what triggered a separate browser for Sailfish to begin with).
Please please please :D<p>Use this chance and port Firefox to Qt:<p>There are a lot pro`s, who speak for that, front in the row the huge community, the portability, the performance, and the fact that many devs rewrite there existing GUI to Qt, like Musesore, Frescobaldi, Wireshark, Subsurface, VLC, Gcompris, Mkvtoolnix, Dropbox, Megaglest`s Map editor, OpenShot, ufw-frontends, Dolphin-Emu and even two DEs: LXDE and Unity.<p>Please do that and i am Firefox user for my lifetime. :)
Good thing is servo team is supporting API compatibilty with chromium CEF project. That mean, if you write an html5 app using CEF, it will just work so with servo engine as well.
It would be cool if they took something like NWjs or Electron and made it better. So we could build other apps besides a browser with a cross platform framework.
Please keep these little icons unchanged, i don't care about it.<p>Do not make tabs cuter, I don't care about it.<p>But PLEASE - do something to stop Firefox from being such a bloated memory hog - I deeply care about it.
I'd rather they'd spend more time making their rendering engine e.g. implement the SVG spec properly[0] than fanny about with this, but, y'know, I'm not in change.<p>[0] <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=437554" rel="nofollow">https://bugzilla.mozilla.org/show_bug.cgi?id=437554</a>