Why Mozilla Is Committed To Using Gecko 632
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?
Because... (Score:5, Informative)
It's required for the XUL based interface?
Re:lite (Score:4, Informative)
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 (Score:5, Informative)
Webkit doesn't specify that you have to use a separate process for each page. That's a Google Chrome feature.
Re:Heterogeny (Score:3, Informative)
Re:lite (Score:2, Informative)
IE 8 has threaded tabs. Now, granted, that's in beta, but that means that the biggest browser has picked up this feature. Chrome also has it, albeit with processes instead of threads. Note I'm not picky about the technical details of threads vs processes, I just want the browser to not completely hang (or worse, crash) based on one tab's misbehavior.
Like I said, given that IE 8 is implementing threaded tabs, there's no excuse for Firefox not to have it. It just brings too much to the table in terms of reliability to not have.
Re:lite (Score:5, Informative)
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 [mozilla.com] (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:No chrome until adblock and flashblock (Score:3, Informative)
You're wrong. Some plugins and extensions have been ported to Webkit, but the thing keeps on crashing. I'm sure this will change, but Webkit is just not a stable platform to extend right now.
Re:Woah... (Score:3, Informative)
Modifying a value more than once in a single sequence point is undefined behavior [google.com].
Re:lite (Score:1, Informative)
...it's trivial to figure that out. Let me explain it to you: you have tab A, and tab B. If tab A and B share the same thread, they will hang each other if one of them hangs. By putting them in separate threads, tab A and B can hang, but not affect each other.
How is that hard to see? It's not exactly a great insight.
RTFA (more closely) (Score:4, Informative)
Re:lite (Score:2, Informative)
Even if Firefox used threaded tabs, it wouldn't stop the browser from crashing if one tab screwed up. If one thread in a process crashes, the entire process crashes.
Re:lite (Score:3, Informative)
And because people confuse that, they tend to post misinformation.
IE8's tabs will be in separate processes despite what the grandparent said. This adds stability.
Re:lite (Score:2, Informative)
Note I'm not picky about the technical details of threads vs processes, I just want the browser to not completely hang (or worse, crash) based on one tab's misbehavior.
If you aren't picky about the details then you don't understand the problem, and thus the solutions and why Threads don't give you protection from misbehaving browser windows/tabs and processes do.
Re:lite (Score:3, Informative)
Re:lite (Score:5, Informative)
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.
Re:Heterogeny (Score:3, Informative)
Then I suggest you look into forms and faxes, because it's impossible. Even a problem as simple as screensize means a difference in layout. PDF and ps solved this whole perfect layout thing, but as it turns out, it's damn near impossible to write for.
Re:The real question is ignored here... (Score:3, Informative)
Ugly UI? Safari generally(*) uses the standard OS-supplied features.
That's specifically one reason why I don't generally use third party GUI browsers anymore (I use lynx or links once in a rare while). I like the idea of Firefox, but the UI is just "weird". It's close to, but not exactly the same as the real OS supplied UI. Maybe there is a variant of it that uses standard UI nowadays, I'm not sure. It at least used to be 'skinned' to be almost-but-not-quite the real UI, where things like control tracking don't work the way everything else does.
So I guess that's another good reason there's choice. We seem to like different browsers for partially the same reason the other DOESN'T like the browser.
(*) One specific example where it does not, is the 'tab bar'. Safari doesn't use a regular tab control, which I wish it did.
Re:lite (Score:4, Informative)
I don't see why this was modded troll - it's a very accurate statement, even if it shows !Mozilla in a good light (even MS, *gasp*). I haven't used a computer with less than a gig of RAM in about five years, and a lightweight app is no good to anyone if it crashes every hour. Firefox has been relatively stable for me all things considered (except for some rogue JS at digg which I abandoned a while ago, I rarely have issues), but Chrome's approach of sandboxing tabs so they don't kill each other probably should have come around tabbed browsing 1.1.
It would be one thing if this approach bloated up Photoshop or something (as if PS wouldn't burst if it got any more bloated), but I spend ALL DAY with my browser open - dozens of tabs often spread across a couple windows. Firefox taking 400MB of my 4GB doesn't bother me considering how much of my time it gets (though since 3.0 and disabling Firebug, it's not usually near that bad), so taking a little more of my system's memory in order to significantly enhance stability is more than worth it.
Hell, even in my pre-Firefox days (actually, I think this was everyone's pre-firefox days, as I'd made the switch around the time of the old mozilla naming fights), I could almost emulate this by digging for that old setting somewhere in the bowels of explorer preference to make each IE6 window run it its own explorer.exe process. And as you might expect, the system as a whole became fantastically more stable upon doing so. IE6 was (and still is) as crash-prone as ever, but it wouldn't take out my other browser windows nor the main GUI process when one took a nosedive (the decision to make the browser and the desktop run in the same process by default has always been well outside the grasp of my understanding). In any case, that should have been a tip-off that each tab should have its own process. To be fair, that setting is so buried that I'm probably one of about five people in the world to have used it (hell if I still know where it is), but there was still an important lesson there.
That comic doesn't really tell us a lot. (Score:3, Informative)
Separating the browser into one process per tab only helps for the fragmentation problem in the case of memory that is truly private to each process. It doesn't help at all in the case of memory that's shared between processes. If that shared memory is managed as a heap like malloc and free do, it can still fragment. (And it's important to point out that the shared memory doesn't need to be managed like that; a custom memory management scheme tailored precisely to the way it's used could have zero fragmentation.)
There is no way of knowing the memory and performance costs of the multi-process browser without having a lot more detail about precisely which things are private to each process, and which are shared. The comic does nothing to tell us to what Chrome is sharing and what's private to each process, nor how any shared memory is managed.
Security? (Score:3, Informative)
2008-09-05: http://milw0rm.com/exploits/6367 [milw0rm.com]
2008-09-05: http://milw0rm.com/exploits/6386 [milw0rm.com]
2008-09-05: http://milw0rm.com/exploits/6372 [milw0rm.com]
2008-09-04: http://milw0rm.com/exploits/6365 [milw0rm.com]
2008-09-03: http://milw0rm.com/exploits/6355 [milw0rm.com]
2008-09-03: http://milw0rm.com/exploits/6353 [milw0rm.com]
WebKit isn't touching my machine, thank you very much. Might throw Bunny(the fuzzer) at the codebase, though.
Re:Gecko, Mozilla and XPCOM (Score:3, Informative)
Whoa there buddy. Close but no cigar.
XPCOM is by no means a re-implementation of MS COM. They share some basic ideas (and so does CORBA, if we're going that far), but "reimplementation" is not a word I would use.
Another thing to point out is that you can bridge almost any API into XPCOM. XPCOM and WebKit isn't an XOR, you could (probably) provide XPCOM interface to WebKit
Re:Heterogeny (Score:3, Informative)
Flash is an example of something that seemingly progressed well, perhaps faster than browsers, while having essentially no competition.
It's not quite what it seems to be...
You make some interesting points, and your point about Flash isn't entirely invalid, but Flash is also a great example of the sheer lunacy of pinning any kind of "web standard" on a single closed implementation from a single vendor.
Let's start with the basics: Flash is slow. Version 10 might finally get hardware acceleration -- OpenGL has been available for how long, again?
Firefox already uses Cairo, a cross-platform vector graphics engine, which already has some acceleration, and is having more added to it -- but, being its own library, Cairo should be able to benefit other projects than Firefox. Flash hardware acceleration only benefits Adobe products.
Flash video is an absolute nightmare. It's probably the worst possible way to give me a movie to watch. All the controls must be done in Flash, or in the surrounding HTML -- which is great for particularly control-freak designers, but sucks if I want to, say, attach my own controls? (Think Apple Remote on a Mac, or just a global hotkey on Linux.) It's slow -- absurdly so, on the order of ten to a hundred times slower than any other video player I could find.
Yes, that slow. I compared with mplayer and VLC on Linux with Adobe's Flash player. I used the Video Downloader extension to grab the FLV. Turns out, mplayer and VLC use maybe 2%, if I go fullscreen. Flash uses 50%, even in a tiny YouTube window, and is unwatchably laggy fullscreen.
And, you see, if you give me any other format -- Windows Media, Quicktime, mpeg, Theora, Dirac, whatever -- it'll load up whatever player I decide to plugin to my browser. If one sucks, I can use another.
But see, Flash has no competition, and gives me no source code, which means that when things don't work well, I'm SOL.
I believe Gnash is finally good enough to watch YouTube, or getting close -- but keep in mind how many years Flash was out, and how much catching-up Gnash has to do. And Adobe's not helping -- the spec is still proprietary; you can get it under a license which basically lets you do anything you want with it, except develop a player. (WTF? Why anything but a player? Don't they make their money from the server products and creators anyway?)
Now, it's true, Flash was able to include shiny new features faster than browser. But when browsers do include those features, they get done right. Look at the HTML5 video tag -- not quite as many features as Flash, but out of the box, it'll talk to Javascript (so you can write those controls in AJAX), it's trivially easy to add to a page, somewhat more lightweight, and it's entirely up to each browser how they want to implement it -- nothing stopping you from giving the user some playback controls of their own.
Safari already has it -- ties into native QuickTime, I'd guess, which means it should be fast for h.264 and such.
Of course I've been saying for a while that MS should pick up either Gecko or WebKit and not create another rendering platform.
If MS could get it right, I'd say they should go ahead and keep using their own, or develop a new one. The more the merrier.
Where we see problems are when MS gets it horribly wrong, and the entire fucking industry has to pay for their mistakes.
Process-per-tab protects you from rogue JIT (Score:4, Informative)
Chrome's doing JIT compilation of Javascript. [blogoscoped.com] 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 (Score:5, Informative)
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:The real question is ignored here... (Score:2, Informative)
Have you ever tried to embed Gecko into an existing program? It's an absolute nightmare. All popular Gecko-using applications are actually written *in* XPCOM because it's easier to write an entire browser in XUL and Javascript than try to bind Gecko to a sane language like C or Python.
Re:lite (Score:3, Informative)
Are processes really that much heavier? (Score:3, Informative)
The downside is that processes are a lot heavier than threads.
How much heavier are they? Off the top of my head, the big internal advantage of threads is that they share the same page tables whereas separate processes have their own... but, each thread is still going to have its own stack and its own state block for when its task gets switched out.
Correct my own stone age knowledge of the Linux kernel, but, aren't threads and processes practically the same thing internally anyway?
Which Gecko? (Score:3, Informative)
I have an old 12" powerbook with 384 MB of RAM. It started gathering dust when I got a much larger laptop for work, since modern ajax-and-flash-heavy websites were really crawling with so little memory, and that's using both Firefox 2 and Safari. When Firefox 3 came out, I heard how much lighter it was, so I gave it a try. Lo and behold, my old laptop had new life! Safari still feels a little snappier when I only have one tab open, but that's a fleetingly rare condition. Gecko isn't just the technology we have right now, it's the vibrant developer community hard at work making it better. WebKit has less ambitious aims, and achieves them well, but Mozilla would be throwing the baby out with the bathwater if they told everyone to forget Gecko and learn how to do that same optimization work on WebKit.
Re:Gecko is not outdated or bloated. (Score:2, Informative)
I guess you missed the second page ;) (Score:2, Informative)
Re:lite (Score:3, Informative)
you're still right that they're not magic bullets and they have a host of new issues to consider (although they make a whole host of other ones go away, and can be much friendlier in the right model).
Re:Heterogeny (Score:3, Informative)
Re:Gecko, Mozilla and XPCOM (Score:3, Informative)
One distinct advantage of using XPCOM is that the idl is language neutral. There may be occasions where you don't want to implement an object in C++, or that object resides in another process or thread. XPCOM allows you to implement an object in JavaScript or any other language with a binding. XPCOM also has marshalling code so the caller and callee could even be running in different threads. Neither even cares what the other is implemented in because XPCOM takes care of everything. This is why a substantial amount of Firefox is actually implemented in JavaScript and the rest is largely platform neutral.
Yes there are occasions where XPCOM is not suitable. XPCOM objects are memory allocated and don't live on the stack (although you can cheat in some circumstances). There can also be an overhead in creating some objects (e.g. from a class id or string), and there is small overhead associated with querying the interface and reference counting. This means XPCOM is best suited to long lived objects, especially ones that represent or are passed between subsystems. It isn't suitable for temporary objects or objects which are used in very tight loops such as string classes and so on.
Anyway yes you could wrap WebKit and the overhead would likely be miniscule. Create an interface to represent whatever WebKit object you want to encapsulate and then do the minimal marshalling to connect the two worlds. After all, Safari manages it in Objective-C. I really don't see any big deal doing the same for XPCOM. The issue of course is why bother. Gecko is a robust, fast, mature and fully featured rendering engine. What point is there in junking it and stuffing another engine in instead?
Personally I see very little about Chrome (and I've run it) that justifies why they bothered with WebKit to implement it. Chrome could have been implemented in chrome (XUL) fairly easily from what I've seen.
So the problem is C/C++ actually. (Score:3, Informative)
Because in other programming languages, NULL pointers can be caught as exceptions, and the thread can be gracefully terminated.
Re:Thread INTERACTIONS are hard (Score:3, Informative)
> The whole point was that generally, these separate tabs will have very little need to interact.
I'm not really familiar with browser internals, but I'm guessing that there must be at least some points of common interaction
- document cache
- nameservice cache
- connection sharing (?)
- configuration
- font resources
- system libs (e.g. image rendering)
- cross-frame/cross-window.open javascript
- GUI container rendering
My post was really a counter example, though. The OP suggest that just slapping each tab into a separate thread would somehow magically make the browser more stable by allowing threads to hang or crash separately.
Other posters have made the point that appropriate design fixes many of these issues -- but design is hard to bolt on after ten years of development. Especially when innocuous things like this can mess you up:
On SOME memory architectures, in multi-CPU configurations, the output could be "0 1" or "1 0", even though you'd expect "1 1" -- think how a.i and a.j are incremented, some arches will read double-ints out of the struct and put 'em back as double ints.
Now, obviously, this is a contrived example, but it's a great one for showing that MT design really does need significant forethought.
(And I _did_ preview. But whoever wrote the new CSS for the ecode tag is clearly a numpty)
Re:lite (Score:5, Informative)
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")?
Re:So the problem is C/C++ actually. (Score:3, Informative)