I've not blogged in a while, but now we've released, I figure it's time to break radio silence. Since we were assimi^Wacquired, I've been hard at work on browser bits. I've already blogged about the headless Mozilla back-end and accompanying Clutter library; since then we've created a Mozilla services daemon and we've made the source code for the browser public.
I've been meaning to blog for a while about Mozilla, and the current trend of abandoning it in favour of WebKit. I'm not against WebKit and there are definitely advantages it has over Mozilla in certain situations, but I'd like to highlight some of the great things in Mozilla and why I think we ought to reassess the whole webkit move.
Comparing Mozilla and WebKit is quite a difficult task. They're extremely different. Yes, you can use both to render web pages, but WebKit won't do much more and it's the least that Mozilla can do. This difference affects things at pretty much every level; their structure, their API, their coding styles, their build systems, everything. I'd also say that, in the long run and given its current maturity, this is a huge advantage for Mozilla. Want a download manager? Just use the built in Mozilla download manager. Want to override it? Sure, that's fine, just implement the interface and register it at run-time. This is the same for pretty much any component you can think of that may be required for anything web-related. Use WebKit and you'll have to implement all of these things from scratch, there's no fallback option (generally). On the other hand, the WebKit API to implement these things will probably be a bit nicer. Swings and round-abouts.
And that whole run-time overriding thing? Very cool. Pretty much everything in Mozilla has an interface definition and is accessible and overridable via XPCOM. At runtime. Anything that uses Mozilla has a powerful and accessible extension mechanism, something that I don't believe WebKit can boast. Not only does it have this mechanism, but there's already a huge community of talented developers that are well versed in it.
The last advantage (that I'll mention) that I think Mozilla has over WebKit is a slightly political one; From my experience (and this is purely anecdotal, I don't mean to offend anyone), the Mozilla developer community is a lot more open and a lot more willing to take risks. I think their extensible architecture helps this, but it does seem to be a prevailing mindset amongst Mozilla developers. They really want to see Mozilla succeed in every way, and to encourage its development in all directions. Obviously, I'm sure the powers that be also want to see WebKit succeed, but it's not the innocent, wide-eyed enthusiasm that I'd like to think embodies Mozilla developer spirit. The fact that I've been given a repository hosted upstream at Mozilla.org for our headless backend says something, and the amount of support and encouragement I've received from Mozilla developers has been nothing short of astounding.
So why exactly did we (Gnome) abandon Mozilla? Maybe people thought that contributions to the gtk embedding API (which has some annoying bugs and an API that could really use some love) wouldn't be accepted? From my experience, I think this would be highly unlikely. Why exactly are we creating an entirely new backend and API for a new rendering engine (an API that bears an eery resemblance to gtkmozembed anyway, in a lot of places) when we have a perfectly capable, and in fact more than capable platform, funded by a foundation and accepting of contributions? There are a lot of problems with Mozilla. I do wish they used autotools, for example, and I've often run across a bug in my code that's down to me not having some obscure and highly undiscoverable knowledge... But these problems can be fixed... And are becoming fewer... So what's the deal?
Neil Roberts says:
I agree that Mozilla's everything-and-the-kitchen-sink approach is quite handy if you are making a browser and it's nice to be able leverage the existing components. However I think Mozilla would also be a lot better it was split up into chain of separate projects that depend on each other in a hierarchy instead of one monolithic build system.
I imagine there is no reason why you couldn't make a kitchen-sink browser library that uses webkit at its core. And that would be the right way to approach it - first make a project for the rendering engine, then a project for the download manager etc. Why can't Mozilla do the same and split out its rendering engine to a separate library? It's such a pain to build and link all the cruft that comes with Mozilla when you know you are only working with a small portion of it.
Søren Hauberg says:
The goals of the two projects are simply not the same: webkit is about making a browser, while mozilla is about making a Free internet. I have a hard time understanding why Free software developers, would not choose the latter.
Emmanuele Bassi says:
I tend to agree with Neil on this; look at xorg, and how beneficial was the move to a monolithic monstrosity to a number of small(er) modules.
Dylan McCall says:
But here's where you are incorrect, Søren. WebKit is less about making a browser than Mozilla is; it is about making a web content rendering engine. I would love to support Mozilla, (they have a cool web site and a nice vision) but I don't get the impression I can use their technology in the same way I could use WebKit.
If I want a rich graphics presentation that can be modified (in terms of behaviour) in a way that appeals to artists, a nice option is leveraging web presentation technologies. Here's where Webkit comes in: I create a WebView widget and I get Just That - nothing more. (Okay, a bit more; its handling of the right click menu and Forward / Back by default is a tad annoying when it doesn't create any other interface).
It's like presenting any other content to the user; you throw that widget in, but the widget should not make any assumptions about what it's for. (That's why it has other widgets surrounding it, and a functioning set of commands).
Look at it this way: what would people think if GTKImage started to throw in a slideshow section that people had to opt out of?
AB says:
make a similar post about thunderbird
i still cant find a reason why gnome uses evolution as a default mail client
tretle says:
My knowledge of the two is not that detailed but I do know that unlike what you have suggested webkit does indeed have a download manager so that sorta ruined the post for me. It also scores higher on acid tests which makes me wonder about your mozilla renders better argument. And there are plenty of nice innovative things in the pipeline for webkit, 3d css work is woking on the iphone and its only a matter of time before its migrated to the main build of webkit.
ethana2 says:
Just make it work with gnome-globalmenu, gnome-keyring, and horizontal scrolling over the tab bar for navigation, and you've got a full time user back.
Sam Morris says:
The problem with gecko is that it is horribly buggy.
For months I have endured three incredibly irritating bugs in Epiphany. First, the download manager will randomly de-register itself, which causes gecko's own download manager to take over. This also causes a variety of weird and whacky effects (including making it impossible to close any tabs!) that basically make the browser unusable until it is closed. Did I say closed? I actually meant, until I bother to fire up a terminal, hunt down epiphany's process ID, and kill it. That's not user-friendly.
The second bug is that Epiphany will crash whenever a page containing a Flash movie is closed.
The third bug is a random crash inside some function whose name I forget, it contains 'atoms'. It's impossible to reproduce on demand, but it crops up several times a week.
Over time, I have grown to endure these bugs, simply resigning myself to enduring bug-buddy's tedious insitance on generating a stack trace that, if sent to bugzilla.gnome.org, will only be RESOLVED DUPLICATE. Yes, these bugs have been identified, and forwarded to Mozilla's bugzilla, but there they have simply rotted, while users abandon Epiphany in frustration. Occasionally a bugzilla.mozilla.org administrator will close them due to inactivity, and I have to go back and confirm that YES, they STILL crop up and stab me in the face with clockwork regularity. But no one seems to give two shakes about actually fixing these bugs that by all rights should have forced by to abandon Epiphany in frustration.
Mozilla upstream simply does not give a crap about anything other than Firefox.
Well, this week I started to use Epiphany with the webkit backend. It does have one or two missing features, but they are irrelevant compared to the vastly improved stability of the browser. epiphany-webkit is simply a long-overdue breath of fresh air.
Alessandro says:
Couldn't just agree more with Mr. Morris.
But I have to say, it doesnt even matter whether i use(d) epiphany or firefox they both crashed way too often.
David Love says:
I have a lurking suspicion that embedded work might have something to do with this as well.. The light-weight nature (relatively speaking) of WebKit is an advantage in that space.
Andrew Fuchs says:
Summarized, WebKit renders web pages, while Mozilla (XULRunner) is a whole application framework. Mozilla has been used to make applications by using the web (Songbird, Miro, eMusic's downloader). Most uses of WebKit I've seen just display web pages, and chose to use it because of its simplicity.
Gustavo Noronha says:
I think the real question is not why people are turning their backs to Gecko, but why should they stay? Mozilla should prove that they care about embedders and give them a light-weight, simple API that doesn't require horrible hacks to configure.ac each release, like it promised it would:
http://www.0xdeadbeef.com/weblog/?p=359
Adam Williamson says:
I'm with all of the above; the problem with Gecko is its take-it-or-leave-it, overengineered, monolithic design. It's worth remembering why Firefox was such a raging success among enthusiast users when it first came out, compared to the Mozilla suite which - despite being around for years - wasn't: Firefox was a simple, no-fat, nimble web browser. Since that time the Mozilla project has got busy turning Firefox back into the Mozilla suite (it gets fatter with each release), while not really making much progress on splitting Gecko up into proper separate reusable components that other applications can build on without lots of pain and without having to deal with a lot of stuff they just don't need.
Michael says:
Adam got the point. Firefox is Mozilla's primary goal and after that, there's a huge gap of nothing. Still beyond that, there's "support for 3rd party applications built using Mozilla tech". This usually means using the whole stack, XUL and all. Even this is very low priority for Mozilla and gtkmozembed is even much much lower. Same for the question "why not ship Thunderbird in GNOME instead of Evolution": Thunderbird, as Firefox, is not a GNOME application.
Chris, your comparison of Gecko VS WebKit has one mayor flaw btw. You should not pick the WebKit porject in general, but one special flavor. For GNOME stuff, this would naturally be WebKitGTK, which is how things should be done.
clee says:
Because Gecko doesn't feel native. Period.
It doesn't feel native in GNOME, it doesn't feel native in Mac OS X, and it doesn't feel native on Windows.
And it's not an easy problem to fix, because Gecko's codebase is an order of magnitude larger than WebKit's, and properly fixing it for even one platform would require significantly detailed knowledge of that platform's internals AND the Gecko internals. There aren't a lot of people with that knowledge around, and most of them have no interest in fixing these things.
Also, ignoring the issues of toolkit look and feel, Gecko is just a terrible X11 client. It creates unnecessarily large backing pixmaps, it makes calls to sqlite when you resize the browser window, and you can't have two processes using the same Gecko profile open at the same time. Gecko's JavaScript performance is pathetic on Linux, even with the latest 3.5 beta. Simple things like scrolling feel sluggish. Fedora's Firefox 3.0 even shipped with a bug that resulted in full system lockups for several seconds at a time, thanks to a combination of Firefox using sqlite and calling fsync a lot along with the default ext3 behaviour being set to data=ordered.
The Mozilla devs have never really made "amazing performance on Linux" a priority. Maybe if they actually pretended to care, people wouldn't be ditching their platform for the first viable alternative.
Chris Lord says:
A lot of fair points made here. The monolithic nature of Mozilla is annoying and it would be a lot easier to manage if it were broken up into logical components, a la Xorg. This isn't an impossible task.
Also, re the download manager, WebkitGtk has a download manager by default? How would that even work? I find that a bit hard to believe... (and by download manager, I mean you click on a URL and it handles all user interaction for starting, displaying and accessing downloads) I should probably have another look at WebkitGtk though, its been a while now.
Pretty much all of the downsides people have mentioned here are true (and I could talk about a few more), but I don't get the attitude that it's Mozilla's place to be fixing these problems. Keeping WebKit in mind, yes, Mozilla's GTK backend needs work and the embedding API is pretty terrible, but both are mature and exist. Mozilla devs are incredibly friendly and helpful, if we relied on Mozilla in our platform, why weren't we working on Mozilla itself? Our contributions would've been welcomed, I'm sure.
Having worked with both WebKit and Mozilla, yes, the barrier for entry is a little higher for Mozilla, but it's not so much higher that instead of choosing to work with the existing Mozilla platform, I'd write an entirely new backend for an entirely new rendering engine. Especially given the relative difficulty in contributing to WebKit vs. Mozilla (something that I think has been ironed out now, but it certainly used to be a problem).
I'm a little amused by the comments about Mozilla only caring about Firefox too... Not just because that's not really true, but also because what do people think Apple care about? It'll be interesting to see a little while down the line when bugs like those currently in Mozilla appear in WebKit and to see if they're handled differently. Do many Apple devs work on WebkitGtk?
Chris Lord says:
Oh, and @clee:
That's actually just not true (about the native widgets, at least). The code that handles native widget drawing in Gecko is tiny and sectioned off from pretty much everything else. Both WebKit/Gtk and Gecko handle this in the same way and I don't see WebKit feeling any more native than Gecko, other than the small point that you can stick a WebView inside a GtkScrolledWindow (which wouldn't be that hard to do with Gecko either, though indeed that does require a bit more knowledge).
I use Firefox every day on my Linux machine and it's pretty native feeling to me. The bits that aren't I'm thankful they aren't (GtkNotebook is pretty terrible at handling lots of tabs, for example) and it even has some advantages over true 'native' engines like gtkhtml3. Try messing around with selections for example (double-click + drag, triple-click + drag).
Vadim P. says:
Do Input Methods work in Firefox now (so I don't have to type in another gtk+ app, and copy/paste text into Firefox in the year of 2009)?
Xan says:
@Chris
For now Apple engineers have shown to care more about GTK+ embedding than the Mozilla engineers, and they have spent a lot of their paid-for time helping us with all our problems and issues. I have never felt that my project mattered less than anyone else's, or that my concerns were being sidetracked because the priority #1 was Safari. Being attracted to an empirical understanding of the world this matters a lot more to me than some, at best baseless, claims about "wide-eyed enthusiasm", which at the end of the day do not tend to fix a lot of embedding bugs by themselves. When Mozilla starts to deliver on their promise of decent embedding APIs then I'll be sure to reassess my opinion on this matter, but for now I think WebKitGTK+ provides a friendlier experience to GNOME embedders (both in terms of its actual API and in the goals of the project).
Second, and maybe I'm missing something here, but if the fact that you have your own repo in mozilla.org servers says something, does the fact that the GTK+ embedding code is in WebKit upstream say something more?
Both Mozilla and WebKit are great free software projects, run by great people, and I think both are doing great things to move forward the Web experience (even more, and I think I've said this in the past already, I think Firefox is without doubt the most important open source application there is). When you ignore that and start to throw around insinuations about the actual hidden intentions of someone you simply lobotomize any technical discussion, it's the equivalent of "Will someone please think of the children" in politics. So let's stick to facts and leave that kind of thing for others, I think we can and should do better.
Chris Lord says:
@Xan
Well reasoned, can't really argue (much) with that. I'm still not really sure why it was chosen to write an entirely new backend and API than to fix what was already there in a welcoming project though. WebKit probably is a more attractive prospect now (arguably) because the people developing it are the same people (or are closely related to those) using it.
Given the time investment in Webkit/gtk, which I don't want to devalue because I think it's great work and certainly WebKit is a better fit in some situations (embedded being the biggie), wouldn't the same investment in working with Mozilla have produced something even better/more useful?
Of course, this is all conjecture, but that's the point of a blog, right? :)
Vadim P. says:
By the way, Apple's efforts in helping get the gtk+/gobject into webkit are shown here:
https://bugs.webkit.org/show_bug.cgi?id=16401
Just read the @apple.com and @webkit.org replies :)
Alessandro says:
Couldn't just agree more with Mr. Morris.
But I have to say, it doesnt even matter whether i use(d) epiphany or firefox they both crashed way too often.
clee says:
@Chris:
There's a LOT more to feeling native than rendering the pixels correctly (and Firefox didn't even do THAT right up until a few releases ago.)
Granted, this isn't exactly a Gecko-specific issue, but XUL (and, by extension, Firefox) doesn't follow icon settings that you specify in GNOME. If you say "Text below items"... Firefox just draws toolbar icons. If you say "Text beside items"... Firefox just draws toolbar icons. If you turn off "Show icons in menus" ... Firefox shows icons in menus.
It doesn't feel native. Firefox feels like an alien trying to pretend to be human by wearing a human corpse, and Gecko has all of the issues I listed above and more.
Chris Lord says:
@clee:
Ok, but then that's why we should use Gecko for rendering and have our own native interface, right? Like what Epiphany/Galeon/etc. were doing until we decided that Gecko had too many bugs that we weren't willing to track down and fix?
I agree there's more to feeling native than just pixels, but then these same problems will apply to any rendering engine, and for the record, Gecko (not talking XUL) gets a whole lot more right than gtkhtml3 does.
I guess I'm a little disheartened that after having worked on this backend, I've seen how easy it could be to fix a lot of the bugs that people complain about (in both Firefox and gtkmozembed), but it's like after the code was written, no one cared enough to take a look at it. I suppose there are only so many hours in the day...
Simon says:
My perception is that for most of the Gnome use-cases (i.e embedding an HTML renderer into yelp, into Evolution, into anything else that needs HTML rendering), WebKit is a much better fit than Gecko. Gecko feels like something much bigger - it's a platform to build on, rather than something to embed.
Gustavo Noronha says:
@Chris: you keep arguing that the effort that is going into WebKitGTK+ should have been directed at Gecko, being Mozilla an extremely welcoming project.
I have two answers for that:
1. It's a good thing to have alternatives; it's good that we have XFCE/KDE/GNOME; if we are able to talk, and work together, it's awesome that we can choose the right tool for the job; WebKit has been a driving force on many advancements, and it's awesome that we can benefit from it with a simple GObject API, if we decide it's the best thing to do.
2. Mozilla is NOT as welcoming as you seem to imply, and I would welcome you to search Mozilla's bugzilla to find out how much time got spent in trying to do exactly what you are saying wasn't tried: fixing the bugs that hindered applications. It would make this conversation much more sane if you stop trying to make this point. It's not as if people have been just complaining, and are now turning their backs. Bugs have been filled, patches have been written, hours have been spent trying to move forward.
Now, I'm not saying WebKitGTK+ is perfect. I know of at least one bug in Epiphany that is caused by a limitation in gtkmozembed that still exists in WebKitGTK+, but I am hoping (and my experience up to now has been) that we will be able to get these issues fixed in WebKitGTK+ with less effort than what has been already put into Mozilla with no good result.
Even if this was not the case, like I said, having a G* API to interface with WebKit is a great thing to have, even if only to be able to choose the right tool for the job. Notice that I don't want to start a Gecko vs WebKit war; I think having Mozilla around is a very good thing, and I think also having WebKit gives GNOME as a platform a very good set of capabilities. I really wish the embedding API I talked about earlier will be around to improve upon the current situation, and that Mozilla will be more modular in the future. I wish all the best for those who are working on this!
As for Download; I worked on designing/writing the download API for WebKitGTK+, and it's a design decision that there's no UI - I am pretty sure every application which cares about having a download manager would want to override it, anyway, but it does perform the actual download for you, and has nice signals and properties so that you can track progress. It's very glibish, simple, and easy to use, in my opinion. If you have improvements to suggest or find bugs, please file a bug =):
http://webkitgtk.org/reference/webkitgtk-WebKitDownload.html
See you,
willy99x2 says:
I briefly looked at the two. Mozilla has a huge API. It reinvents everything (XUL? Do we need another GUI toolkit? Especially one built on technologies completely unfamiliar to most non-web developers?). If I want a maintainable piece of code that embeds Mozilla, it's gonna take me a few months to get up to speed. If I want developers to join my project, there's now a huge learning curve.
WebKit is small and simple enough that I can understand it.
More so than anything else, that makes WebKit much better for use in other places.
mark says:
Autotools are not the only problem - if they would support a configure like interface for people to compile it from source, I would be happy.
I can understand people not wanting autotools, but I cant accept if people develop as if the rest of the world in the open source movement isnt using something else (cmake, scons and especially a utotools)
David Bolter says:
Competition is good. Mozilla is about choice.
Gustavp says:
Sorry, but since when is Mozilla a render engine, and not a company?
Fabio FZero says:
Ok, everything is fine and Mozilla is great, but since you're talking about moblin, can I talk about Maemo?
Please kill Fennec. It sucks beyound repair. It's a pretty clear case where webkit would be much better - and we have Midori (a light, webkit-based browser) for the N800/810 to prove this.
Adam Williamson says:
Fabio hits on an illuminating point, actually - mobile browsing. Mozilla has been trying to bring out a mobile browser for years. Minimo started in, what, 2003? And now there's Fennec. In that time - at least six years - Mozilla's managed to produce extremely buggy, under-featured, under-performing alphas (or pre-alphas) for a limited set of devices. That's not exactly a stunning record.
Compare the alternatives: Opera has two extremely awesome mobile browsers, Opera Mini and Opera Mobile. Apple has a pretty decent browser on the iPhone (which uses Webkit). Hell, even the latest version of Internet Explorer's mobile version sucks less than anything Mozilla's ever released, and that's setting the bar pretty damn low. There isn't a really significant non-Apple Webkit mobile browser, but as Fabio points out, Midori apparently works pretty nicely on Maemo.
As far as I know the people who've worked on the mobile projects for Mozilla are pretty skilled, enthusiastic and committed. Yet in five years or more, they've yet to release a single really usable browser for a mobile device. I suspect that comes down almost entirely to the inadequacies of Gecko - it really just doesn't work as a platform to build a light, nimble browser for a mobile device off of.
Urukhai says:
Why does 'screenshots' and 'user guide' links on your webpage links to some video page?
I clicked on screenshots to see screenshots. Is it that unusual?
David says:
Adam: Minimo was not a Mozilla project. It was completely independent. Mozilla has been working on a mobile browser for barely a year—since Firefox 3 was released, and Gecko’s performance was deemed good enough for mobile devices. Fennec is still in development. So, your statement that Mozilla “has been trying to bring out a mobile browser for years” but can produce only buggy alphas makes no sense at all. Please inform yourself.
Justin says:
@Adam 6 years? No, that's a mischaracterization of Mozilla's mobile efforts. Minimo was basically a side project by a couple of engineers, and afaik by 2006 they had largely stopped working on it. Fennec, on the other hand, only started up a year and a half ago, has serious resources backing it, and has been making rapid and steady progress towards a 1.0 release. The two projects don't really have anything in common.
Maybe Mozilla should have gotten serious about mobile earlier (though the lack of compelling hardware is an argument against that), but to make it sound like they've been slaving away for 6+ years with nothing to show just is flat out misleading.
Daniel says:
I prefer embedding WebKit because even though embedding some C into another object model (haskell, python, scheme, .net, java) is slightly cumbersome, it's nowhere as painful as dealing with another monstrous object model and component system like XPCOM.
Haven't a lot of Gnome devs moved away from Bonobo for the same reason?
Maciej Stachowiak says:
@Adam Williamson
You said, "There isn't a really significant non-Apple Webkit mobile browser". What about the S60 Browser for Nokia devices, the Android browser, Torch Mobile's Iris Browser, or the forthcoming Palm Pre?
Adam Williamson says:
Maciej: I sort of forgot about those :) (and I didn't know Iris was a webkit browser). You're quite right, thanks.
Adam Williamson says:
David / Justin: fair enough, but the 'corrected' position still does not exactly reflect well on Gecko's ability to be relatively easily cut down to a decent size/performance situation to build a mobile browser, does it?
Chris Lord says:
A lot of interesting points made and I think I've had my eyes opened a bit. I still think that Mozilla (and I use 'Mozilla' as a term for the code that builds all the apps in the mozilla platform, not the foundation) is worth spending more resources on. Not at the expense of WebKit, mind, but still.
To think that we aren't leveraging the web platform that has the largest market share (bar Internet Explorer) to its fullest extent is a bit of a shame. That, and I think there's a lot of misinformation about the resources (memory and CPU) really required to run recent Mozilla code vs. WebKit, I'd be interested in an informed comparison.
@Gustavo: Also, liking the WebKit download API, gotta hold my hands up on that one :)
@mark: Mozilla does have a configure - https://developer.mozilla.org/en/Configuring_Build_Options - Note that although it says you have to create a .mozconfig, the parameters can be specified on the command line.
Boris says:
> because Gecko's codebase is an order of magnitude larger than WebKit's
Would you mind backing up those numbers? Last I compared, the difference was a bit under a factor of 1.5, with webkit steadily gaining in size..
Robert O'Callahan says:
Webkit/GTK+ actually uses the GTK theme rendering code from Gecko. At least as far as Web page rendering goes, the native-ness of the look should be identical.
Many of the graphics performance problems we see on GTK systems are due to poor XRender implementations in drivers. If other browsers don't see them, I presume they're not using cairo-xlib much. We've been hoping drivers would get better, but I think we should probably just give up and use cairo-image surfaces, rendering everything without X locally and then shoving the final results over to X at the end.
Robert Grønning says:
Speaking strictly from a end-user point of view:
FireFox is painfully slow compared to other relevant browsers like Google Chrome, Chromium and Safari, especially on limited hardware specs.
When one tab in FireFox crashes, entire FireFox with all it's tabs crashes.
How about porting the entire Chromium browser to Moblin, and just change the GUI to match the current Moblin webbrowser GUI?
Charlie Melbye says:
@robert: Now there's an idea... Chromium has always been very quick, responsive, and reliable in my somewhat limited experience with it. Linux compatibility is getting really good these days, and they're working hard on getting that even better.
Robert Grønning says:
Apart from the following three annoyances ... :
* BUG: "Sending Requests for Twitter to follow Protected Updates gives 403" bug (http://code.google.com/p/chromium/issues/detail?id=17752)
* BUG: "closing tabs is slow" (http://code.google.com/p/chromium/issues/detail?id=15453)
* Lack of a fully working Adobe Flash plugin
... I feel that Chromium@Linux is up to par with Google Chrome@Windows.
Hopefully these two bugs will be gone by the time Moblin 3 is released, I also suspect that Chromium will gain full flash-support very soon.
Robert Grønning says:
Update: Both bugs I mentioned has actually been fixed now, and Chromium has gained support for the Adobe Flash plugin
Any comments?
