[Sugar-devel] Browse and the move to WebKit

[lkcl luke]

On Tue, Feb 21, 2012 at 7:59 PM, Brendan Eich <brendan at mozilla.com> wrote:
> I asked Benjamin Smedberg, who replied as follows:

 thank you for notifying the right people, brendan.
 related bugreports:

 https://bugzilla.mozilla.org/show_bug.cgi?id=728645
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660482

> "
> pyxpcom is still actively maintained by toddw (activestate). I'm not clear
> on what sugar/olpc actually desire here: the pyxpcom code works about as
> well as it ever did.

 right.  when it doesn't result in segfaults it's absolutely superb,
there's no question of that!

 there are only two versions still running that people can actively
use, that have been confirmed as working:

 * python-xpcom with xulrunner 1.9.1 (and 1.9.2) - the changes made
which broke things were the xpcom interface changes.  i'm extremely
grateful to todd for getting xpcom up-and-running again but it's taken
this long for it to happen!

 * python-xpcom with xulrunner 9.0.  this i tested with
pyjamas-desktop last week: it works as perfectly as it ever did (with
only one outstanding bug for code that's not really properly paid
attention to, out of thousands of functions and properties that's not
bad! the function i'm referring to is Canvas2D DrawImage.  it just...
doesn't work, period.)

 the problem is that because python-xpcom and hulahop gets so little
testing, on a sort-of "yes i have time right now, nobody else is doing
it or has done it for almost 2 years so i'll give it a shot" style of
testing, the various gnu/linux distros have *already* moved on!

 so *already*, nobody gives a stuff about xulrunner 9.0!

 but.... xulrunner 10.0 is broken, and xulrunner 11 has moved on even
further and python-hulahop and python-xpcom don't even compile / link
against xulrunner 11!

 this is what i mean when i say that xpcom needs to be *reinstated*
from its third party status *back* to a fully-comprehensively tested
piece of code, as part of standard release cycles (see below for more
on that).

> It has limited automated tests, though...

 yes, because... it's middleware, and up until pyjamas-desktop came
along _and_ hulahop came along, there wasn't really any
declarative-style programming environment which could be used to
properly give python-xpcom a workout.


> arguing about
> whether it is "third party" is a bit irrelevant, especially since the code
> is still hosted on hg.mozilla.org.

 well, its status is severely downgraded, and python-xpcom itself
*doesn't* actually test the xulrunner GTK front-end, does it?

 whereas python-hulahop, which is a pygtk c-code-based widget, and
thus, being also a GTK widget, *does* flex the "xulrunner gtk muscles"
so to speak.

 this is where things go wrong, because it activates *different*
codepaths from that which iceweasel (aka firefox) activates.  case in
point:



> If they have additional automated tests as part of pyjamas-desktop, are they
> asking us to run thoses tests on our release infrastructure?

 well, there are actually two projects that use hulahop.  ok, in the
case of OLPC that's no longer the case because the lack of attention
to python-xpcom resulted in them pulling the plug 6 months ago.

1) olpc-sugar web browser
2) pyjamas-desktop

the olpc-sugar web browser "activity" as they call it is very very
basic, but it uses python-bindings to History, python bindings to
"Load Event Notification" etc. etc. and basically does everything that
you'd expect a real web browser to be, including show progress
notification and so on... just all from python *not* java, not
javascript and not even c: it really really is all python.

the pyjamas-desktop environment is a leeetle different: it utilises
the *ENNNTTIIIIRE* HTML5 DOM API (aka NPAPI) and when i say the entire
DOM API i am not arseing about here i really mean EVERYTHING.  NPAPI
Timers, NPAPI objects (all of them), NPAPI events (*all* of them),
NPAPI properties - everything from getElementsByTagName to onmouseover
to XMLHttpRequest.

and this is done solely and exclusively from python, using python-xpcom.

but as it's effectively turning the DOM API into a Widget Set API
(equivalent to python-wxwidgets, pygtk2 and pyqt4) it makes _less_
usage of the things like progress notification etc. because it's using
the exact same hulahop plugin purely as a "full-screen window".  a
blank sheet, effectively.

the point is: the two projects *don't* have anything in common (not
even shared developers).  the only thing that *was* in common was the
fact that they shared python-hulahop.

and unfortunately, the situation got so bad that the OLPC developers
decided to pull hulahop 6 months ago: david was in fact so pissed off
and felt so let down by the mozilla foundation that he now flatly
refuses to even use firefox.  at all.


> Or just pay some set of attention to the bugs filed?

 well the problem is that because there's no active testing as part of
releases, there are codepaths that simply don't get tested, memory
corruption that corrupts "unused" areas of memory on firefox which
*are* critical data-structures when you go via the hulahop code-path,
and so on.

 and, because the code is *not* tested properly (with hulahop included
as part of the testing), it "works okay with firefox", a 10.0.2
release goes out the door... but then we found that there are *two*
separate segfaults... and these cannot be fixed!

 although one of the bugs has been fixed it doesn't impact firefox so
there is no incentive to create a special release.  and it would take
a special 10.0.3 release of xulrunner just to include that "specially"
to cope with the code-path that python-hulahop covers (and the
different memory layout etc. etc.)

 but worse than _that_ is the fact that, from what i've heard (from
the debian mozilla maintainer) is that python-xpcom doesn't even
compile against xulrunner 11, because it's *already* moved on!

 so whilst yes it would help enormously for these bugs to be fixed, it
still *won't* help unless hulahop is _actively_ included as part of
standard testing *prior* to release - by the mozilla foundation - each
and every release, without fail.

 the easiest and most comprehensive way to do that would be to
actively include some of the pyjamas-desktop tests: yes i have even
written an automated GUI unit testing system.

 now, why i am mentioning this - even though the OLPC team have
abandoned the use of python-hulahop - is because i know that the
webkit-gobject bindings are fundamentally flawed.  so if hulahop is
*not* kept actively up-to-date, not only will the pyjamas-desktop
project not be able to use it, but also when the OLPC team finally
encounter the limitations and flaws in webkit-gobject that i am keenly
aware of and they are not, they would not have any code to return to,
and they would be absolutely stuck with no working web browser
activity.

 so, to summarise:

 * python-xpcom not being part of mozilla-central is causing
python-xpcom to be "out of sync" (for example that massive PRBool ->
bool update)

 * python-xpcom is middleware so *cannot* have comprehensive tests

 * python-hulahop is ironically yet _more_ middleware that joins GTK with NPAPI

 * it's only by the time you get to pyjamas-desktop that the wheels
actually "hit the ground", the clutch is engaged and the whole thing's
in gear, so to speak.

 * the lack of use by the mozilla foundation of pyjamas-desktop or
something similar to it as part of active daily automated testing and
proper and official release cycle validation (validation which can
cause a block on release of xulrunner) is what's causing us massive
headaches, leaving the whole "python access to mozilla foundation
technology" as a real hit-and-miss affair.

 what's particularly irkesome - from a free software perspective - is
that there are absolutely NO such problems with MSHTML, Microsoft's
HTML Engine (Trident).  none.  it took me 3 weeks to write
pyjd/mshtml.py - it works, it's stayed working, it works with
MSHTML.DLL from IE6, IE7, IE8 and IE9, and we simply haven't had *any*
problems, period.  and the underlying engine - Trident - is not even
free software!

 by contrast, the webkit developers were *actively* hostile towards
the webkit-gobject contributions, such that they're now fundamentally
flawed, and the xulrunner / python-xpcom / hulahop bindings are left
completely to chance.

 this isn't a good advert for free software! :)

 l.