[joshmoz]

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.

[ykl]

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

[campd]

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.

[Roodgorf]

If that were to happen, how big an impact would that have on Firefox OS development? I admittedly don't understand the project too well, but they had to port Gecko to work in Gonk right? Would there be significant overhead getting Servo working under Gonk?

[fabrice_d]

A few things:

- currently browser.html runs on top of a gecko runtime (called graphene) which is based on the one we use for FirefoxOS.

- getting gecko to work on gonk is not different from adding support for other platforms like linux/mac/windows/android. Basically you need to provide implementation for low level windowing and input events. On non-posix systems there's a bit more to do in the nspr library, but that's not the case for gonk.

- we already have a port of servo that runs on gonk.

FirefoxOS has been using a 100% html UI since about 4 years, so it has been leading the way here.

[Roodgorf]

Very cool, thanks for the information. I'm obviously more ignorant of Mozilla projects than I even thought.

[Manishearth]

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

[dherman]

I agree it doesn't make sense for Servo to be a drop-in replacement for Gecko, but that doesn't mean we shouldn't bend Firefox towards compatibility with Servo. A future Servo-based Firefox is far enough off that it's impossible to predict every step from here to there, but if you ask me, dcamp's email is on the right track: we should evolve Firefox away from dependence on non-standard tech like XUL, XBL, and XPCOM and towards self-hosting on standard web technology and taking full advantage of everything Servo has to offer. What that looks like in practice remains to be seen.

[fabrice_d]

I agree. A key point to achieve that is to define what the embedding api looks like. Right now on FirefoxOS it's partly the mozbrowser api for iframe-centric features, and partly custom events that are dispatched on the top level "chrome" iframe. There's still some cleanup to do there ;)

[Manishearth]

Of course. I'm just saying that from the point of view of Servo, drop-in Gecko isn't really the focus. Making Gecko more HTML-y is a great step for Gecko, but from a purely Servo point of view at the moment it's not really something tangible. Though you're right, it may mean something for Servo a couple of years from now.

[piyush_soni]

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?

[campd]

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.

[joshmoz]

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]

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.

[toyg]

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.

[brandonwamboldt]

It already is. XUL is rendered via Gecko.

[mburns]

XUL is already rendered using Gecko.

[pcwalton]

It already is.

[M2Ys4U]

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

[simcop2387]

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]

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

[simcop2387]

I can't imagine that Firefox on iOS will actually be that useful. Half the usefulness of Firefox is the extensions which I think would violate the store rules on iOS wouldn't they?

[danudey]

The primary usefulness I would see is syncing your browser history, bookmarks, etc. across devices. I use Safari and I have pretty much every extension I feel like I need.

[JadeNB]

Can this be done? The last time I checked, Firefox Sync was only available on iOS via some hacky workaround with an extra (ToS-bending) app.

[rfk]

Yes, proper syncing with Desktop Firefox is a core part of the new Firefox for iOS initiative.

[malkia]

I wonder if there could be some collaboration where firefox, chrome, safari, IE, opera, etc. can exchange and sync - possibly too much to deal with, and might hurt innovation.

[addicted44]

Firefox is my primary browser everywhere but on iOS. It would be nice if I could have the passwords, history and bookmarks available to me on all my other OSes on iOS as well.

This is a huge gap for Firefox IMO.

[nextos]

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?

[rockdoe]

I don't see any relation between the two.

[skybrian]

Wouldn't all Firefox plugins need to be rewritten?

[clarkbw]

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

[JoshTriplett]

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

[Larrikin]

Plugins are the only reason I use Firefox over any other browser.

Can you explain to me why Firefox would be better off if I didn't have Rikaisama for my Japanese studying or one of a number of Youtube plugins that make the site bearable again by forcing annotations off and 1080p on.

[KwanEsq]

You are misunderstanding the language being used.

Add-ons are brower extensions like the examples you provide.

Plug-ins are Flash, Silverlight, Unity Web Player, and the Java plug-in.

Only the going away of the latter is being called for.

[masklinn]

> Rikaisama

This is most likely an addon, a Firefox extension written in (mostly) JS and XUL. Plugins are the external runtimes embedded in browsers with NSAPI &al: Flash, Java, Silverlight, etc...

[Larrikin]

Can't reply, but the annotations off plugin is called "YouTube - Disable Annotations" by notsie

[brobinson]

Awesome, thanks!

Edit: eek, looks like it's been removed by the author :( https://addons.mozilla.org/EN-US/firefox/addon/youtube-disab...

[brobinson]

>forcing annotations off

Please share this miracle you speak of.

[nightpool]

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

[at-fates-hands]

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]

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