Why Mozilla Is Committed To Using Gecko

Ars Technica has published an article about Mozilla's commitment to use the Gecko rendering engine instead of using Webkit, which was adopted by Apple and Google for use in the Safari and Chrome browsers. I have been using Chrome on my work PC and find many of its features compelling, and wonder how soon we will see its best innovations in Firefox. Why is Gecko worth keeping if it is outdated and bloated?

Comments

Because...

[not already in use]

It's required for the XUL based interface?

Re:lite

[Just Some Guy]

You're confusing Firefox-the-browser with Gecko-the-renderer. There's no reason Firefox couldn't have one process per tab, and most Webkit/KHTML implementations currently use one process per browser window (like Firefox).

In short, pick something else to distinguish them. You're way off this time around.

Re:lite

[Anonymous Coward]

Webkit doesn't specify that you have to use a separate process for each page. That's a Google Chrome feature.

Re:lite

[jorgevillalobos]

There is no excuse for a modern browser to not have this, especially in light of the fact that their main competitor (IE) is developing it.

Here's one excuse: complications when trying to have multiple processes render content on a single window in Mac OS X (mentioned near the end of the tab process isolation section).

It's not clear to me if this is impossible or really difficult to achieve, but I think it'll be interesting to see what Chrome does for Mac OS X.

Re:lite

[naasking]

and most Webkit/KHTML implementations currently use one process per browser window (like Firefox).

Firefox does not use one process per browser window. Firefox uses one process per user profile.

Process-per-tab protects you from rogue JIT

[Estanislao Mart�nez]

A thread per tab model does protect you from a rogue Javascript freezing the browser's UI, but it doesn't protect you from a poorly written plugin that does something stupid like dereference a NULL pointer.

Chrome's doing JIT compilation of Javascript. In this context, separating the broswer into multiple processes protects you from bugs in the JIT compiler that produce native code that makes memory access errors.

Re:Heterogeny

[tomhudson]

Yeah, except requiring things to be rendered the same way all the time isn't "harming functionality", it's common sense. In fact, where exactly does one get off saying that you have a "standard" if there's any room for interpretation at all?

It's not common sense. The HTML standard doesn't say, for example, how form controls are supposed to be rendered visually - that's the job for either the browser or the underlying platform.

Ditto with fonts. A 12pt font can be one size on your device/platform, and different on someone else's.

Ditto with web pages themselves - the visual rendering is specified IN THE STANDARDS as being implementation-dependent. For example, a screen reader is free to render web pages as audio instead of glyphs and images.

Read the standards. They're posted at w3c.

Then learn proper design. A good workman doesn't complain about his or her tools.

Re:lite

[jhol13]

There won't be any locks

The difference of threads v.s. processes has nothing to do whether there are locks or not.

If you have a shared resource you must use locks - no matter if you use processes or threads.

I do not know about Chrome but I'd imagine it does not use shared resources (separate windows, sockets, etc.) which may or may not be a good thing (share cookies of several tabs?). Or maybe it locks only for a (provably) short time ("getGlobalCookie")?