There's Interest Again In Embeddable Gecko To Better Compete With Chromium CEF

[azari]

[...] I've been running Firefox Nightly, which is Firefox 46, with e10s enabled and it's still not able to tackle Chrome for speed and performance - at least not on Linux. [...]

They are still only using one content process, so right now the only difference is the UI and content run in separate processes. As I stated previously, they don't have any resource management or load balancing yet to spawn new processes as-needed the way Chrome does. This will get solved eventually, but the problem is that getting legacy XUL/XPCOM addons working with e10s is complete and utter hell; a huge part of the WebExtensions project is about creating an extensions API that fits in better with e10s.

In short, this isn't going to happen overnight, there are several milestones here; first of all, we need to see e10s ship in a release version, so that Mozilla can gather more testing/data in the real world; then they have to eventually get multiple content processes with some load balancing and resource management; and finally once they start deprecating XUL/XPCOM extensions and switching to WebExtensions, they will become free to refactor and cleanup internals that they have never been able to touch before.

Servo doesn't magically solve any of this because the extensions migration has to be done for Servo as well, since there is no way in hell that Servo will be compatible with XUL/XPCOM, and yet that issue is what has kept Firefox back all these years; once you make it possible to alter the internals without breaking extensions, we should see a lot of progress there.

[Michael_S]

That's because Firefox has not yet implemented multiprocess (e10s), they are working on it but it has been really difficult to do this without causing too much damage to the addons ecosystem; at the moment they're supposed to ship e10s with version 46, but even then there will still just be one content process and one UI process, it will take a bit longer for them to implement the resource management necessary to automatically spawn new processes and load balance them the way Chrome does. This is basically one of those "legacy codebase" problems that ended up requiring an insane amount of rework, but after years of work, it's finally close to fruition. (More details below in my response to SystemCrasher.)

Again, I like Firefox and I like what the Mozilla team is trying to do, and I trust them with my privacy much more than I trust a company that makes its entire income through targeted advertising.

But I've been running Firefox Nightly, which is Firefox 46, with e10s enabled and it's still not able to tackle Chrome for speed and performance - at least not on Linux. Maybe the situation is better on Windows. And to be fair to the Mozilla folks, Windows is the bigger market. But if Firefox 46 on Windows is like Firefox 46 on Linux, the battle is still lost and switching more resources to Servo seems like the right move.

[azari]

azari Great post. There's just one thing I'd like to point out: XUL is FAST. Much faster than any HTML5 Firefox (or Chrome for that matter) can render, which is why browser.html as a concept has never been brought up seriously before. However, with Servo's architecture, HTML5 is getting very close to XUL speeds. With WebRender finally pushed to master, it's probably a little faster at this point. Much more reliable, at the very least... and much less buggy.

That's interesting. Why has the UI always felt so sluggish compared to the UIs of websites then? I don't think it's only lack of e10s because even on developer edition the UI still doesn't feel like it's as fast as what's going on inside the content area of the browser (although it's way more responsive in e10s for sure).

I remember when they were porting Firefox to Android and they decided to get rid of XUL and make a native UI because of performance issues, and that's what gave me the impression that XUL was slow; given that a "native UI" on Android is still basically done in a high level language (Java), it gave me a bad impression of XUL. Could it be that XUL just doesn't thread as well or something, and thus feels less responsive even if the rendering speed is faster?

I'd love to read more about the subject of XUL and browser.html, and the motivations/wins that come from the changes, if you have some blog posts on it or something.

[Daktyl198]

azari Great post. There's just one thing I'd like to point out: XUL is FAST. Much faster than any HTML5 Firefox (or Chrome for that matter) can render, which is why browser.html as a concept has never been brought up seriously before. However, with Servo's architecture, HTML5 is getting very close to XUL speeds. With WebRender finally pushed to master, it's probably a little faster at this point. Much more reliable, at the very least... and much less buggy.

[azari]

While I would normally agree with your logic, my experience with Linux has been that Firefox is so far behind Chrome that the race is already lost. I say that as a fanboy for Firefox that still runs Firefox. But I run Firefox for ideological reasons, not practical ones - because in day to day usage Firefox for Linux just doesn't hold up to Chrome. I get pauses and hangs and even complete crashes in Firefox, and Chrome just trucks along.

That's because Firefox has not yet implemented multiprocess (e10s), they are working on it but it has been really difficult to do this without causing too much damage to the addons ecosystem; at the moment they're supposed to ship e10s with version 46, but even then there will still just be one content process and one UI process, it will take a bit longer for them to implement the resource management necessary to automatically spawn new processes and load balance them the way Chrome does. This is basically one of those "legacy codebase" problems that ended up requiring an insane amount of rework, but after years of work, it's finally close to fruition. (More details below in my response to SystemCrasher.)

Imagine Linux would go for implementing Win32 API, ditching POSIX and eventually being like WinXP but worse. [...]

Honestly, it's more like the reverse. Firefox's XUL/XPCOM is more analogous to a decrepit old legacy piece of crap, whereas Chrome's API, while perhaps not designed to be portable initially, has a clean enough design that it serves well as a starting point for such a portable API, and even Microsoft is planning to support Chrome extensions at some point. The part you seem to have missed about Firefox's WebExtensions project is that it is NOT going to be identical to Chrome's, it will rather be a SUPERSET of Chrome's APIs; in other words, they are planning for all extensions that are possible now to still be possible afterwards, they are going to add their own APIs to it, and they are only using Chrome's API as a starting point, because where is the gain in starting from scratch?

[...] Chromium already implements e.g. isolation by using Linux containers facilities (aka clone() with appropriate unshare flags). Mozilla isn't anywhere close to it, while it hardly takes a small launcher and few syscalls and google did it many years ago. Reaching far better security under Linux than Mozilla did.

It's not as easy as you think. Firefox has been working for years to make their browser multiprocess (read my response to Michael_S above), whereas Google just used WebKit, which was based on KHTML, and as it was a cleaner and newer codebase they were able to design the browser for multiprocess from day one, whereas Firefox had to essentially figure out how in the hell to get their legacy addons to work in a multiprocess world, which is practically impossible because the addons API in Firefox isn't so much an API, as it is just raw access to the entire core of the browser, so anytime you change even one little thing in the core, your extensions break. This is why they finally decided to change the extensions API, and actually isolate it from the core, so they can make changes without constantly worrying about breaking extensions in the future.

The greatest irony here is that everyone complains about them getting rid of XUL/XPCOM, but no one realizes that XUL/XPCOM is pretty much the reason for all of the other things you hate about Firefox, but paradoxically it's also been the reason for the things people like (namely the extensions it allows), so the only solution is to create a new extensions API that is rich and featureful, but doesn't constantly break the way XUL/XPCOM does.

Firefox on android: like a crappy beta, stuttering and tearing is hallmark of Firefox.

I haven't had this experience personally; I actually prefer the way Firefox works on Android, and I like the tab management better.

Now they seems to think it wasn't enough. So let also remove XUL, extra settings, dumb down settings UI to be totally not in line with OS themes, just because Chrome did the same. And then they mumble about api being like a chrome. Fine, and what has left from Firefox? Firefox was known for customizable UI and useful add-ons. Chrome addons can barely add button to toolbar, that's where their ability to extend browser UI ends. Mozilla is going to be like this? Fine, but it likely means no TabMixPlus, no DownThemAll, etc. So speaking for myself, there is no point to use their techs. Especially after they got gready and ecosystem inclined, so they do not even allow to configure new tab URL, so we have to watch their ads, and like if it wasn't enough, they also locked out unsigned add-ons with no sane means to override.

I responded to the XUL thing above, it's terrible and you will be happy it's gone, when it is, trust me. As for the settings UI, the problem is that the web has evolved significantly over the years to the point that web browsers are now frameworks/toolkits, so it's odd to hook what is essentially a toolkit, into another toolkit (sup dawg, i heard you like toolkits), just to draw a few dialogs that could easily be drawn by the browser itself, and faster in some cases too. There will always be a need to hook into the toolkit for stuff like the "File Save/Open" dialogs and so on, but getting the browser to draw more of it's own UI is a win, and there is a project to eventually get even the main UI made in HTML5 instead of XUL (browser.html), which will likely make it snappier since I doubt the legacy XUL codepaths are as fast as HTML5.

As I mentioned before, you're wrong about not being able to extend stuff anymore; the whole point of WebExtensions is to create a superset of the Chrome APIs, not just implement only what Chrome has. They have mentioned on their WebExtensions page as well as in various blog posts that they want extensions like NoScript, TabMixPlus, ClassicThemeRestorer, TreeStyleTabs, Vimperator, Tab screenshotting addons, Toolbar addons, etc to be possible in WebExtensions. This is not the same thing as Chrome's API, this is Chrome's API on steroids. (Also check out the native.js proposal, for more info on how new WebExtensions stuff will be prototyped in the future.)

Unsigned addons are controversial because they form another reason for Firefox's drop in marketshare over the years; there are a lot of ordinary users that will unintentionally install malicious addons, and this is a huge problem for security because as I mentioned earlier, XUL/XPCOM APIs basically hook directly into the browser core. However I agree that it would be nice to at least have an about:config pref for it, but we'll have to see how this discussion matures. In the meantime, Firefox Developer Edition won't ever require addon signing, and it's more or less the same product except with some additional web dev tools, which you can remove if you want. Linux distributions may also choose to compile Firefox without requiring addon signing, but I don't know if/when that will materialize.

If it looks like a chrome, behaves like chrome and so on, it could make sense to take e.g. Chromium, at least Google engineers can afford expertise to use Linux containers, unlike Mozilla. They also develop quite good video codecs for the web, I like how VP9 performs. NaCl isn't bad either. Mozilla ... lacks any techs which I would consider exciting. It has been like this for ~5 years or so.

Mozilla, Google, Cisco, and even Microsoft are actually working together on a next generation video codec to try and beat H.265/HEVC; previously Mozilla was working with Xiph on Daala, which was supposed to be the video equivalent of the Opus audio codec (which was also developed with the help of Mozilla). Whatever codec emerges from their collaboration is going to be the future, and will likely finally break the MPEG-LA's stranglehold on the video codec world.

So it going to be like a Chrome. And why we need 2 chromes? When it comes to Mozilla vs Google, I bet my $100 on Google, sorry. [...]

You might lose your $100. As I mentioned at the start, Mozilla has been held back by their legacy codebase and by XUL/XPCOM in particular. In essence, the reason all this happened was precisely because the developers felt that breaking compatibility with the addons API would be too invasive for most users, because addons are what Firefox was all about; it's people like you that have scared them away from fixing Firefox's real problems all these years, because they anticipate the fallout of such a huge compatibility break.

The situation has now become dire enough that they've decided to finally give up on XUL/XPCOM, which is a good thing, and once the transition happens, and addons get ported, I guarantee you that every user will be thankful for it. It will also make the future evolution of Firefox so much easier, without having to constantly worry about "will this change break one of the 100,000 addons that people rely on?".

Far from the recent changes being a sign of Firefox's "demise", as has been the common interpretation, it's actually the opposite; this new change in direction signals that there is finally hope that Firefox is going to make a comeback, the phoenix is rising once again. =)

[liam]

So Mozilla rode whole pack of horses. Just to figure out they are jumping in different directions, so Mozilla is about to end their bold story lying on ground and swearing. They are not in position to waste resources on crap which does not pays for itself, yet they did it, multiple times. Sure, Google pwned 'em. Being forced to mimick Chrome both visually and extension-wise is a loss of own self for mozilla, and if they are up for being another Chrome skin, they can enjoy by their 2% of market share, like Opera does.

I'm NOT saying they aren't driving benefits from rust/servo. They've already begun the process of exchanging c-like libraries used by Firefox for ones written in rust and used by servo.
Something like servo is the future, but SERVO may not be it.
There are several reasons why they had to change their extension system, and none of them should result in "a loss of own self for Mozilla". The biggest reason, again not the only one, is that they have to provide a well defined interface for their extensions so they can "sandbox" the browser.

[SystemCrasher]

Hate? I think it would be better to describe it as "strong distaste" and "lack of respect to technical achievements of this team".

Why it happens like this? Say, AFAIK, Mozilla still fails to acknowledge their ideas about addons signing weren't ecactly best. Instead I hear lame excuses about delaying armaggeddon one version, or maybe two, and it keeps going like this. Hilarious. For me it appears they're either became terminally greedy and closed-minded or maybe they're unable to learn from their own mistakes. Both options are IMHO unexciting. Maybe there're better excuses, but I fail to see them.

[Daktyl198]

SystemCrasher I can't even justify typing up another post to point out how wrong you are about 90% of what you said, because (just like I pointed out in my first post) you don't care. You've got it all set in your mind and you refuse to listen.

The only thing I will say is that Firefox isn't even my daily driver, Chrome Beta is. I'm upset with many things Mozilla has done (e.g. the addon signing fiasco) and that won't change. But I don't let blind hatred get in the way of facts.

[SystemCrasher]

Do... you not know what an API is? The compatibility with the CEF API means that Servo can be dropped in as a replacement to any software embedding Chromium with CEF, NOT that Servo is anything like Chromium. Because it's not. It's very, VERY different than any rendering engine available today.

Imagine Linux would go for implementing Win32 API, ditching POSIX and eventually being like WinXP but worse. What it would be? ReactOS? Ha-ha, you can take a look on this one, to get a very clear idea how this approach performs.

Can you tell some sane reasons why someone would be interested in Mozilla and their creations over Chrome techs? Google is large company who can afford bunch of skilled engineers. Chromium already implements e.g. isolation by using Linux containers facilities (aka clone() with appropriate unshare flags). Mozilla isn't anywhere close to it, while it hardly takes a small launcher and few syscalls and google did it many years ago. Reaching far better security under Linux than Mozilla did.

At this point, I think you're trolling. Everybody knows the whole "Firefox is copying Chrome" thing was exaggerated. "

Maybe. At the end of day, I'm utterly frustrated what Mozilla has became. I've enjoyed their browsers until... until Firefox 3 or so. Then ... then they always managed to piss me off with some misfeatures. Eventually it has gone so far I had to change my browser. Since it took some efforts and woes, I'm not a big fan of Mozilla techs and especially new directions anymore.

Just to give you idea:
- Chrome on android: flawless video on the web.
- Firefox on android: like a crappy beta, stuttering and tearing is hallmark of Firefox.

And by the way, it is one of very major use cases. If Mozilla can't afford get this one right, who would use their things at all? Sorry, but if some program or team performs like a crap, I do not have any issues to tell obvious, nor I feel myself anyhow bad, because no point to conceal the truth.

Oh no, they moved away from square tabs and changed the icon for their one-button menu! TOTALLY RIPPING OFF CHROME" is something nobody says anymore.

Now they seems to think it wasn't enough. So let also remove XUL, extra settings, dumb down settings UI to be totally not in line with OS themes, just because Chrome did the same. And then they mumble about api being like a chrome. Fine, and what has left from Firefox? Firefox was known for customizable UI and useful add-ons. Chrome addons can barely add button to toolbar, that's where their ability to extend browser UI ends. Mozilla is going to be like this? Fine, but it likely means no TabMixPlus, no DownThemAll, etc. So speaking for myself, there is no point to use their techs. Especially after they got gready and ecosystem inclined, so they do not even allow to configure new tab URL, so we have to watch their ads, and like if it wasn't enough, they also locked out unsigned add-ons with no sane means to override.

The change in tab design was going on behind the scenes for years before it actually happened, it has nothing to do with marketing or market share. And the menu button may look similar now, but the menu itself is nothing like any browser.

Sure, its not copying, or just half-copying, or maybe they copied 75% or 80%. Even if they copy 90% of chrome appearance and attitude... uhm, what is the point of this shinese fake of Google Chrome? If it looks like a chrome, behaves like chrome and so on, it could make sense to take e.g. Chromium, at least Google engineers can afford expertise to use Linux containers, unlike Mozilla. They also develop quite good video codecs for the web, I like how VP9 performs. NaCl isn't bad either. Mozilla ... lacks any techs which I would consider exciting. It has been like this for ~5 years or so.

As for the extensions, it's not that they're copying chrome, they're just taking inspiration to help new developers while also decreasing the burden on the Firefox devs who have to take into account addons before making any change to the browser (even minor changes to the XUL ffs) because the current SDK is so permissive.

So it going to be like a Chrome. And why we need 2 chromes? When it comes to Mozilla vs Google, I bet my $100 on Google, sorry. They showcased at least some examples of technical excellence. Mozilla showcased lame marketing and bunch of incompetent script kiddies instead.

But you're an idiot and a troll and won't read a single word of this other than to refute it stupidity, so I'm not typing this for you. I'm typing this for anybody that reads your crap and might get the wrong ideas.

To sum it up: you're Mozilla fanatic who has got his ego hurt, because your "gods" proven to be just a bunch of mediocre apprentices at very best, right? Just by looking on their "achievements" in techs and utter lack of own ideas, so they have to copy whatever Google does. And your best objections were calling me idiot and troll. Sure, it was splendid idea how to prove you're right.

[Daktyl198]

So they could ditch their efforts on Servo, trash rust and openly admit their browser is going to be skin for Google Chrome. The very same result for end users and devs, but 100x less efforts and already-working, battle-hardened solution in place. There are no rational reasons to stick to Servo or Rust at this point. I think it is pretty clear Google has prevailed and there is no point to waste time on doing a third-rate ripoff of Chrome when one can just grab Chromium source.

Do... you not know what an API is? The compatibility with the CEF API means that Servo can be dropped in as a replacement to any software embedding Chromium with CEF, NOT that Servo is anything like Chromium. Because it's not. It's very, VERY different than any rendering engine available today.

So Mozilla rode whole pack of horses. Just to figure out they are jumping in different directions, so Mozilla is about to end their bold story lying on ground and swearing. They are not in position to waste resources on crap which does not pays for itself, yet they did it, multiple times. Sure, Google pwned 'em. Being forced to mimick Chrome both visually and extension-wise is a loss of own self for mozilla, and if they are up for being another Chrome skin, they can enjoy by their 2% of market share, like Opera does.

At this point, I think you're trolling. Everybody knows the whole "Firefox is copying Chrome" thing was exaggerated. "Oh no, they moved away from square tabs and changed the icon for their one-button menu! TOTALLY RIPPING OFF CHROME" is something nobody says anymore. The change in tab design was going on behind the scenes for years before it actually happened, it has nothing to do with marketing or market share. And the menu button may look similar now, but the menu itself is nothing like any browser.
As for the extensions, it's not that they're copying chrome, they're just taking inspiration to help new developers while also decreasing the burden on the Firefox devs who have to take into account addons before making any change to the browser (even minor changes to the XUL ffs) because the current SDK is so permissive.

But you're an idiot and a troll and won't read a single word of this other than to refute it stupidity, so I'm not typing this for you. I'm typing this for anybody that reads your crap and might get the wrong ideas.