There have been various discussions in the past suggesting a move from mozilla to webkit for the Browse activity and related components, but I've never really been convinced: there is always a cost to switching, and convincing-looking numbers from webkit supporters tended to be countered with convincing-looking numbers from mozilla supporters.
But now I believe there is a new reason for the switch to WebKit: necessity. === Mozilla === First, why I've become convinced that Mozilla is no longer a viable option in the face of alternatives: I've been looking at a bug where Browse can't pass the focus from a normal GTK+ widget to a text input field inside the hulahop browser window. I think this bug was added in xulrunner-1.9.2 (over v1.9.1). We are not the only ones to conclude that embedding xulrunner-1.9.2 into your own app is totally broken: https://bugzilla.mozilla.org/show_bug.cgi?id=533245 Until xulrunner-2.0, mozilla provided a "gtkmozembed" widget within mozilla, a GTK+ widget that you could use to trivially embed a Mozilla-based web browser window to your GTK+ app. We didn't use it (presumably because it was a bit simplistic) but our "hulahop" equivalent had a lot in common and was no doubt built from knowledge of gtkmozembed. Mozilla have now removed gtkmozembed altogether because it was unmaintained and doesn't represent "the direction we want for embedding in general" yet I've been looking and I can't find any example which *do* represent what they want. If they did want to influence the right direction on people they should provide good examples. But the clear message from http://groups.google.com/group/mozilla.dev.embedding/msg/98cb5d92e48f5d01 is that embedding isn't a concern for Mozilla and they acknowledge that it hasn't been given the support it deserves. They are taking steps to make embedding actively harder and actively discourage against using mozilla in this way: https://groups.google.com/forum/#!topic/mozilla.dev.embedding/c_NMcO-N8wo/discussion Also, the mindset in which mozilla is developed seems to sit a long way out of our traditional open-source ecosystem (where we aren't bugged by problems like DLL hell). They have gone in the direction that enables you to build and install a mozilla-using application without having mozilla installed. The mozilla stuff can then be located at runtime and used. Here are the hoops they now put us through as of xulrunner-2.0, enabling this approach (which is of little use for us and just seems ridiculous): We want to call the function XRE_InitEmbedding() inside libxul. This is the first thing you need to do if you want to embed mozilla in another app. XRE_InitEmbedding has been removed from the mozilla public headers, so we have to go into the mozilla source so that we can include the definition in our own code. Found it: typedef nsresult (__cdecl *XRE_InitEmbeddingType)(nsILocalFile *aLibXULDirectory, nsILocalFile *aAppDirectory, nsIDirectoryServiceProvider *aAppDirProvider, nsStaticModuleInfo const *aStaticComponents, PRUint32 aStaticComponentCount); Next problem: nsStaticModuleInfo doesn't exist in Mozilla public headers either. As its just a pointer that we don't use (we pass NULL), lets just make it void. typedef nsresult (__cdecl *XRE_InitEmbeddingType)(nsILocalFile *aLibXULDirectory, nsILocalFile *aAppDirectory, nsIDirectoryServiceProvider *aAppDirProvider, const void *aStaticComponents, PRUint32 aStaticComponentCount); Next problem: this function is alive and present in libxul but doesn't exist in the regular symbol table! So we need to use some Mozilla magic to find it: XRE_InitEmbeddingType XRE_InitEmbedding; static const struct nsDynamicFunctionLoad kXRESymbols[] = { { "XRE_InitEmbedding", (NSFuncPtr*) &XRE_InitEmbedding }, { nsnull, nsnull } }; XPCOMGlueLoadXULFunctions(kXRESymbols); Now XRE_InitEmbedding will be set and we can call it like a function. Is this feeling long winded yet? There's more! XPCOMGlueLoadXULFunctions() isn't present in libxul! Because remember, our app can't link against libxul at all. So where does it come from? It comes from libxpcomglue, a static library shipped by xulrunner which we must statically link against, including it wholly inside our app. Now, after jumping through many hoops, we can finally call a function inside the library we are interested in. Now we just have to get through the run-time bugs such as focus issues which have spent months unfixed in mozilla-central... The combination of the fact that mozilla embedding has been neglected over the years, is currently broken and is now actively discouraged, and the fact that general use and design of the library sits way outside of our open-source norms means that I've lost faith in this being a good option for us (and I've got so frustrated by this episode that I've changed web browser on my desktop system as well). === WebKit === What I'd like to do now is spec out a project for someone to take on, moving Browse to WebKit in a way that can be clearly justified for the community. But, WebKit is totally new to me so I have many open questions. Can anyone help me answer them? I'll be collecting the results into a wiki page (to form the above spec). 1. I've only made half the argument above. Mozilla is bad, but why is WebKit the solution? The key questions here are: is it embeddable? Does it work well when embedded? Do the developers support it being embedded? Does anyone have experience here? The name "WebKit" makes it sound nice and modular, and the fact that WebKit itself isn't a browser would seem to support these arguments, but it would be nice being able to argue this on a more solid basis. 2. What is the state of Surf? This is the existing webkit-based browser for Sugar. Does it work well? Is it reliable? What are the gaping holes? 3. What is the safe of pywebkitgtk in F14, F15, F16? This is the backend library used by Surf, right? Is this still the right answer for creating a webkit-based app using Python + GTK? Does it work well on Fedora 14, or do we need a newer distro? I remember at one point there being some pretty key problems with pywebkitgtk causing Surf development to halt. What were these issues and have they been overcome? IIRC those pywebkitgtk-related problems were going to be solved with a move to GObject introspection, which wasn't mature back in that timeframe. But it is mature and usable now. But does this require us to move to GTK+-3? Does WebKit/webkitgtk work for both GTK+-2 and GTK+-3? Any pros/cons of one over the other? Thanks. Daniel _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel