[Sugar-devel] Browse and the move to WebKit

[Daniel Drake]

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