Revisiting how we build Firefox

https://mail.mozilla.org/pipermail/firefox-dev/2015-July/003063.html

by clarkbw • 11 years ago

346 124 11 years ago

mail.mozilla.org

Mozilla has been doing experiments in building browser UI in HTML for a long time. For instance, see Chromeless ( https://blog.mozilla.org/labs/2010/10/chromeless-build-your-... ).

Current HTML is capable enough. It's nice to see them talking about adopting that in mainline Firefox.

agumonkey• 11 years ago

Accidental downvote. I thought it was https://github.com/mozilla/browser.html , I never heard of this chromeless effort.

joshmoz2• 11 years ago

Some context that might help people understand this email...

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.

Firefox, built on top of Gecko, is written primarily in XUL and XBL (and JS).

https://en.wikipedia.org/wiki/XUL https://en.wikipedia.org/wiki/XBL

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.

There are at least three big advantages to doing this:

1. Eliminate the need to support XUL and XBL in Gecko.

2. Contributing to Firefox gets easier because there is no need to learn what are essentially Mozilla-specific languages.

3. Mozilla learns more about what it takes to build complex applications like Firefox itself using Web technologies.

The only real downside is the amount of work involved.

simcop23873• 11 years ago

Another advantage that's not immediately apparent is that it would also open up changing the rendering engine. I think the firefox mobile browser is actually using this to do the main UI on android at least. Along with that there's the browser.html that Servo is using as a base for the browser chrome.

kbrosnan• 11 years ago

Firefox for Android is Gecko. Firefox for iOS which is in the works is playing inside the Apple ecosystem, using WebKit.

ykl• 11 years ago

Could this potentially be a first step towards eventually replacing Gecko with Servo? If Firefox (the application itself) eventually resembles browser.html [1], swapping out Gecko for Servo would be much easier.

[1] https://github.com/mozilla/browser.html

campd2• 11 years ago

It's not not the first step.

That's not the primary driver of this plan. But it might be a happy side effect.

Servo is still in early stages, we aren't making product plans around it.

Manishearth2• 11 years ago

It would certainly help us port Firefox to Servo. But that's never really been a part of the plan.

Gecko and Firefox are quite intertwined. Even if we ignore XUL/XBL, there are things like XPCOM which are still deep-rooted. While this brings us a step closer to making Servo a drop-in for Gecko, this is not a step in a direction we're particularly interested in. At least not now, not that I know of (I'm a volunteer on the Servo team, as such there may be internal plans I'm not aware of).

For Servo one potential way ahead is bringing browser.html up to Firefox's level. Not the other way around :)

piyush_soni• 11 years ago

The only thing I'm worried about is how would it affect performance. Does it mean the UI itself would be rendered using Gecko Engine?

pcwalton2• 11 years ago

It already is.

mburns• 11 years ago

XUL is already rendered using Gecko.

brandonwamboldt• 11 years ago

It already is. XUL is rendered via Gecko.

campd2• 11 years ago

Like pcwalton said, we already use Gecko to render the UI. But we're using a less well-optimized, less well-maintained corner of Gecko.

Improving performance is an explicit goal of this work.

M2Ys4U• 11 years ago

It already is, only the UI is written in XUL.

toyg• 11 years ago

I believe that's already the case, although it uses XUL-specific code paths in Gecko.

In terms of performance -- there is no deep reason for it being slower, but of course the code might end up being a bit less optimized compared to stuff that has been battle-tested for 15 years. On the other hand, getting rid of XUL could deliver dramatic results. It's all speculation really, but there is no real technical reason for "XUL-less FF" to be incredibly slower than current offering.

joshmoz2• 11 years ago

The Firefox (Desktop) UI is already rendered using Gecko. It has been that way since the beginning.

Mozilla spends much more time optimizing HTML and other Web content tech than it does optimizing XUL and XBL. I wouldn't worry too much about this project slowing down Firefox. It might even speed it up a bit.

McElroy• 11 years ago

The e-mail seems to suggest that it would improve performance.

Because XUL and XBL aren’t web technologies, they don’t get the same platform attention that HTML does (for good reason!). Performance problems go unfixed and it creates a lot of unnecessary complexity within Gecko. It’s harder for even experienced web developers to get up to speed. It’s further from the web, and that doesn’t help anybody.

skybrian• 11 years ago

Wouldn't all Firefox plugins need to be rewritten?

clarkbw2• 11 years ago

Firefox add-ons that use the XUL overlay system would need to be written as SDK style add-ons.

nightpool• 11 years ago

a lot of modern firefox plugins are already written this way, but there are probably a significant amount of legacy addons that would need to be rewritten

JoshTriplett2• 11 years ago

Addons that use XUL would need a rewrite, but they already did, as Firefox Mobile doesn't support XUL.

(Plugins need to just go away, and they mostly have.)

nextos• 11 years ago

Will this lead to loosing any of the flexibility in configuring Firefox (all variables you can find in about:config) that is so useful when using e.g. vimperator or pentadactyl?

rockdoe3• 11 years ago

I don't see any relation between the two.

at-fates-hands• 11 years ago

This sounds a lot like what Adobe did with Brackets by building it with HTML, CSS and JS.

The advantages are numerous, so I can understand why they're going this route.

ocdtrekkie• 11 years ago

Hat tip and an upvote for making this super easy to understand.

clarkbw2• 11 years ago

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.

smacktoward2• 11 years ago

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.

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.

simcop23873• 11 years ago

Yep, I remember actually building a toy 2d tilemapped RPG engine with it maybe a decade ago. It definitely wasn't capable of anything fancy then so I didn't do much more than have it let you move around the map with a simple UI around it . Now HTML/CSS/JS can completely blow it out the water with what you can do.

asadotzler2• 11 years ago

IMO, it did pan out. XUL and XBL provided the inspiration for much of what's come to real Web standards over the last decade or so. Thanks to XUL, we had a web-like model for front end dev that over time was usurped by a real Web model for front end dev. If we can re-implement Firefox using real Web standards, XUL will have been be a big part of the reason that became possible.

gsnedders• 11 years ago

And Web Components owe a clear legacy to XBL2 (an abandoned W3C draft, the immediate forerunner to Web Components), which obviously had clear links to XBL (though was backwards incompatible).

smacktoward2• 11 years ago

That's great for FF and Mozilla, but it doesn't feel like a win for those of us who were interested in XUL/XBL as a platform for building our own apps, independent of those Mozilla ships. I put a little bit of time into trying to build stuff on top of XUL before giving up on it, and that time ended up being more or less wasted -- it's not like there was an easy glidepath to take stuff built in XUL and move it to Web standards, because back then Web standards weren't up to the task. Combine that with the platform itself being a bit of a moving target as MozSuite/FF evolved and the end result was work I basically had to throw out.

I'm not mad at Mozilla for all that, lots of platforms are complicated to build on, especially ones that are new and still evolving (which XUL definitely was, at the time). It's just not an experience that I feel like I can put into the "win" category. It was a dead end, at least for my needs.

glorien• 11 years ago

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 so obvious when an app isn't properly using AppKit.

rockdoe3• 11 years ago

You're just describing what sits underneath the XUL or HTML.

IshKebab• 11 years ago

No he isn't?

basch• 11 years ago

Camino was discontinued 3 years ago. https://en.wikipedia.org/wiki/Camino_(web_browser)

k-melon for windows http://kmeleonbrowser.org/

phkahler• 11 years ago

I'm used to agree. That's how you get a native look and feel, but I don't think that's necessarily what people want. I find the use of tabs in the browser to be very telling - it means the way OSes have handled multiple instances of an application are not satisfactory, so people want the browser to handle that. Once it's in the browser people will want it to be the same on all platforms.

kaolinite2• 11 years ago

There's nothing wrong with designing custom UI elements, so long as they're done properly on each platform. For example, Safari's tabs are completely custom (as far as I know) - they can't be used in other applications, they aren't part of Cocoa - but they're tastefully designed and they work well.

blt• 11 years ago

Someone should survey software end users to figure out if they care about native-looking UIs. I have a feeling most users don't care very much.

My most-used GUI apps are Chrome, Visual Studio, Ableton Live, and Photoshop. All of them have heavily customized user interfaces. Their custom controls and tiling/layout systems are tailored to the application domain. Except for Chrome, these are "do your life's work" applications. They should aim for maximum productivity, even if it makes the application harder to use. I think they would suffer if they tried to "look native".

Most everything else is done in web apps these days. Users don't seem to have a problem dealing with different button CSS in different web apps.

Certain things, like the "open file" dialog, really suffer if they look non-native. But I think users don't care about most other cases.

kaolinite2• 11 years ago

Could not agree more.

Firefox has traditionally not been very popular on Mac for this very reason. They've gotten better at imitating OS X slightly, but even today it's still out of the question for me (and I suspect many Mac users) to use Firefox. It feels really awful to use. Whilst Chrome and Safari have nice native scrolling, rubber banding and smooth zooming, just like any other native app, Firefox feels jarring. It only just supports gestures (there's no nice animation like in Safari or Chrome).

My day-to-day browser is Safari. Not because it's faster or technically better (it really isn't) but because it's fully native and integrates properly with the system, e.g. it integrates properly with the downloads folder (showing the progress bar on the file and on the folder icon) and it looks and feels like any other Mac app. Chrome may be faster, Firefox may be more extensible - but I choose Safari because it works properly with the OS.

I really love Mozilla and I would love to use Firefox. I really hope they go with a OS-specific native shell - although I suspect they'll go with building the UI in HTML/CSS. But if they do, there's a good chance I'll switch.

ndesaulniers3• 11 years ago

It's hard for me to believe someone telling me "if it's not 100% native look and feel it's not good" when they're trying to sell something and build a content silo.

The correct thing to use is AppKit on OS X, WPF on Windows, GTK+ on Gnome, and Qt on KDE.

WHAT?! Personally, being asked to rewrite the UI for X different native platforms is rage-inducing.

Some people who write their apps in Web technologies have done native UIs and are sick of the duplicated effort. ;)

jarek2• 11 years ago

As a non-OS X user, I would very much prefer Firefox developer time to be concentrated on things other than platform-specific UI code.

seanalltogether• 11 years ago

Well they're either going to have people writing platform specific code, or people writing code to emulate and keep current with platform specific features.

cookiecaper3• 11 years ago

Agreed. I strongly dislike the philosophy espoused by the parent. "I recognize that other products are technically superior and allow me to do more things without inflicting undue hardship or learning curve, but because the animations aren't as nice, I'm just going to use this other thing." I have no interest in humoring those with such a vain and frankly indefensible perspective.

malkia2• 11 years ago

So if you don't use Gnome or KDE - what should be used? I'm using XFCE at home, and Cinnamon at work.

mappu• 11 years ago

XFCE and Cinnamon are both primarily GTK+-oriented.

Although your point isn't lost. In 2015 Mozilla probably won't release a Motif build for the WindowMaker users.

inDigiNeous• 11 years ago

This would result in bugs between different UIs on different platforms, resulting in duplicated effort and codebase, and many frustrated developers who want to work on feature Y on platform X, and cannot port it to platform Z because of missing support or different implementations.

I don't really care if an application is native or not, Firefox works great for me on Os X and I really appreciate I can run the same browser on all platforms I have to use or developer for.

rockdoe3• 11 years ago

The faster deployment thing seems pretty vague and free of actual content.

azakai• 11 years ago

A few more bits of info from Laura Thompson's presentation, that was mentioned: shipping features can be done even faster if they are done in a modular way, as addons. Firefox supports restartless addons, which means the browser could download an addon and enable it immediately.

Together with work on improving addon APIs (APIs for CSS features were discussed, for example) this could be very interesting.

kazagistar• 11 years ago

If this means that I could easily uninstall all the bits of firefox I don't use, like bookmarks, that would be pretty cool.

ZenoArrow2• 11 years ago

Here's how I read it... they're looking at ways to move towards rolling release for A/B testing.

Think about it like this, you're using Firefox and you get a notification... "Feature X is ready to test, would you like to try it out? Yes/No" If you select Yes, the feature is rolled out to you and other volunteers immediately (potentially without restarting, depending on the feature), and you can then feedback your experience to Mozilla on how well the new feature works out for you. The feedback from this control group then informs whether Feature X is ready for prime time.

In some ways it seems like it's a restructuring of the Firefox development channels, a mix of beta and stable releases in the same channel.

lxt2• 11 years ago

This is kind of what we have in mind.

The model is that we want to make Firefox itself more webby in the way it ships. Features should be independently updatable from the core browser, and we should be able to do phased rollouts to help us watch for issues, control for load, and so on.

We are looking at offering very experimental stuff in a purely opt-in process, and updates to regular features as if they were third party add-ons (with some twists in how they have to be implemented).

lxt2• 11 years ago

It's mentioned only briefly here since the email is mostly about XUL/XBL.

I'm working on the Go Faster project. We hope to deliver a 1-2 features this way by the end of 2015. We have just started on building out needed changes to the client, update service, and build pipeline.

shmerl2• 11 years ago

Is there space for a native-code main-window on desktop like we have on Android?

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?

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

gcp2• 11 years ago

Meego dying killed Fennec. It would have gotten further development if it had had users that warranted so.

shmerl2• 11 years ago

Meego became Mer on which Sailfish is based, and it has enough users, so your argument is invalid.

abhv• 11 years ago

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?

ZenoArrow2• 11 years ago

That's a good question. I don't know the answer, but I'm curious as well. If it is an option, might be a good interim solution, perhaps not for the main UI (where performance is one of the main goals) but it could be useful to help the plugin ecosystem transition over.

ris2• 11 years ago

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.

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=437554

maccard• 11 years ago

Feel free to contribute, FF is an open source project driven by people like you who get annoyed at bugs like this.

ris2• 11 years ago

Many a time I've said this to people but truth is the number of projects I already contribute to is greater than the time I really have to devote to them.

drapper• 11 years ago

That reminds me of what Vivaldi is trying to do (https://vivaldi.com/)

madez• 11 years ago

Does this imply that It wouldn't possible anymore to use Firefox to browse without Javascript?

gcp2• 11 years ago

Firefox already uses a ton of JavaScript internally. The setting for web content has nothing to do with the internals of the browser.

therealmarv• 11 years ago

Keep XUL, XBL. Mark it deprecated. Make plugin development as easy as in Chrome for the new API. Would be awesome and so appreciated!

millstone• 11 years ago

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.

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!

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.

DaveWalk• 11 years ago

Is there an official line that Firefox is taking on this? As a novice to their development decisions, I've always wondered this myself.

I sometimes feel like I can sense when a UI is not native; it's completely useable, and I have no functional complaint, but it might just seem...off.

I felt a small bit of delight when I switched back to Firefox on my Windows machine and saw the snappy animations for new tabs and its menus. It made a kind of subconscious difference.

ianbicking• 11 years ago

There's broadly two directions Firefox could go: do everything in HTML, or use native widgets. Firefox for Android initially used XUL just like Firefox desktop, but switched to native. They've had a lot of success with that. This email is the start of a discussion that will include that option.

frozenport2• 11 years ago

A lot of people agreed with you and built Camino and K-Meleon.

drethemadrapper• 11 years ago

I can't agree more. Where does this plan leave desktop app dev. with Mozilla technologies? There are tonnes of projects (desktop apps) using XUL, XPCOM, e.t.c. SUre, the future is the Web (like Web OS, Unity, i.e. UI in HTML). Why can't they improve on XUL/XBL by releasing a new version with the desired features while they try to simplify building extensions/apps with XPCOMs? They should standardize apps dev. for FFOS (gonk{+necko}/gecko/gaia) & FF(gecko+necko/xul). This effort does not necessarily mean spending much time on enhancing the UI for FF but rather ensuring seamless app. portability between FF and FFOS.

mnarayan01• 11 years ago

I would guess that there's some functionality provided via XUL which doesn't exist in the native OSX context menus (i.e. precisely the same functionality doesn't exist, not that the native OSX context menus are somehow deficient). That's going to be particularly relevant for extensions.

gesman3• 11 years ago

Please keep these little icons unchanged, i don't care about it.

Do not make tabs cuter, I don't care about it.

But PLEASE - do something to stop Firefox from being such a bloated memory hog - I deeply care about it.

chuckharmston2• 11 years ago

Firefox itself is quite fast [1]; if you're having issues, there's a good chance that it's due to an add-on [2]. A (historically; I'm unsure if this is still the case) particularly egregious offender [3] is AdBlock Plus, but µBlock [4] does come highly recommended.

[1] http://arewefastyet.com

[2] https://support.mozilla.org/en-US/kb/firefox-uses-too-much-m...

[3] https://blog.mozilla.org/nnethercote/2014/05/14/adblock-plus...

[4] https://addons.mozilla.org/en-us/firefox/addon/ublock/

gesman3• 11 years ago

I didn't say it slow. It is indeed fast. Thank you for that!

Until suddenly the show stops and I have to kill it via Taskmgr to inject new life into it due to memory suffocation.

sp3322• 11 years ago

Firefox is not a bloated memory hog (anymore).

gesman3• 11 years ago

I'll send you a memory consumption snapshot soon. 8 tabs == 1GB memory already but i can live with it for now. When it eats 3GB+ -- and unfortunately it will - then it'll become an issue.

chovy• 11 years ago

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.

hitlin37• 11 years ago

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.

ShalokShalom• 11 years ago

Please please please :D

Use this chance and port Firefox to Qt:

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.

Please do that and i am Firefox user for my lifetime. :)

Revisiting how we build Firefox

Related Stories