| RE: [eclipse-pmc] On using WebKitGTK |
| "Oberhuber, Martin"
<Martin.Oberhuber@xxxxxxxxxxxxx> Sent by: eclipse-pmc-bounces@xxxxxxxxxxx 03/17/10 02:51 AM
|
|
It's been clear for a while now that using XULRunner as the
basis for the SWT Browser control on Linux has caused significant problems for
our consumers. In current Linux distros, there is a compelling alternative,
WebKitGTK, which is licensed under LGPL. The Eclipse Board has recently approved
a new policy to allow the use of LGPL APIs in certain circumstances. According
to this policy, to approve the request to use the APIs, the board must determine
that:
a) The library or application invoked by the APIs is a “pre-req,”
as defined in the Eclipse Foundation’s Guidelines for the Review of Third Party
Dependencies.
The Browser widget is an optional piece of the overall platform. WebKitGTK integration is an enabling adapter that allows the Browser to work on Linux platforms. Without it the vast majority of Eclipse continues to work.
b) There is no alternative open source software that provides the same or similar function to the WebKit APIs that can be obtained under a more permissive license.
WebKitGTK is the only embeddable web browser that provides a frozen API that is rich enough to meet the Browser's needs and can be counted on to be pre-installed in modern Linux distributions.
c) The functionality, usability or consumability of the Eclipse project would be severely restricted or reduced without the APIs.
Despite being optional, the Browser widget is widely used in end-user scenarios. Without the use of WebKitGTK the instability that currently plagues the Browser on Linux will continue and inevitably reduces the consumability of Eclipse as an application platform for both product teams and end-users.
In determining these things the board may rely on information provided by the PMC, and to help in this disregard, the PMC (with the help of our browser guru, Grant Gayed) investigated and
is pleased to make available the supporting information supplied
below.
<end here with the rest as an
appendix.>
determined the following w.r.t. the above points:
a)
SWT's Browser control has remained stable and reliable on Windows and OS X since
the Eclipse 3.0 release, and there are many Eclipse-based applications that have
a hard dependency on having a working Browser control at runtime. Eclipse/SWT
strives to provide a cross-platform experience that is as consistent as possible
for its applications, so reliably providing a working Browser control on a
heavily-consumed platform like Linux is essential.
b) The goal of the
Browser control is to embed a natively-available web browser without requiring
the user to specially install it (i.e. it should just be there from the OS
installation). WebKitGTK is the only embeddable web browser that provides a
frozen API that is rich enough to meet the Browser's needs and can be counted on
to be pre-installed in modern Linux distributions.
c) Without the use of
WebKitGTK the instability that currently plagues the Browser on Linux will
continue. Given the breadth of Eclipse applications that depend on having a
working Browser control and that wish to target Linux as a supported platform,
this instability inevitably reduces the consumability of Eclipse as an
application platform.
Every major release of XULRunner on Linux has
caused SWT's Browser control to become less-/non-functional, and we have been
forced to adapt it to the native-level XULRunner changes in our subsequent
Eclipse/SWT releases (see http://www.eclipse.org/swt/faq.php#browserlinux). This results in Eclipse-based applications not being able to rely on
their Browser controls to work well on Linux distributions with newer native
browser versions than existed when the application's shipped Browser control was
released.
Consequently, Eclipse-based applications deployed to the field
may become broken at a later date, and maintainers of these applications must
constantly monitor when such breakages occur and issue updates based on
corresponding SWT updates. Alternatively, consumers must specify strict
compatibility requirements to ensure such breakages don't occur, which may force
users to move to older browsers, which may not always be possible. As an
example, given that Ubuntu 9.10 ships with XULRunner 1.9.1.3, an application
must be based on Eclipse 3.5.x or newer in order for its Browser control to work
on this Linux distribution.
A sample of the Eclipse/SWT problems that
have been caused by the need to rely on non-frozen interfaces appear below [1].
Other similar but unrelated problems caused by interface changes have been fixed
without accompanying bug reports [2]. Additionally, significant native
behavioural changes have caused other Browser functions to become broken [3]. A
general question pertaining to these breakages was asked last year (http://markmail.org/message/uapflk6lgkaicsqz#query:+page:1+mid:vdesauobtmoa2n55+state:results ), but the suggestions that were received in response did not adequately
meet the Browser's needs [4]. Being able to rely on OS-provided frozen native
API is what enables other facets of SWT releases to continue to just work for
years without major change, and with the use of WebKitGTK, the Browser control
should be able to provide a similar level of stability on
Linux.
------------------
[1] Example Eclipse/SWT problems caused
by the need to rely on non-frozen interfaces:
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=213194 : setText crash with xulrunner 1.9 stream (+13 duplicates)
-
https://bugs.eclipse.org/bugs/show_bug.cgi?id=214802 : xulrunner 1.9 uses new interface for authentication
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=242644 : eclipse crashes when downloading a file in the internal browser
-
https://bugs.eclipse.org/bugs/show_bug.cgi?id=268651 : Make sure Eclipse works with xulrunner 1.9.1beta
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=296284 : xulrunner 1.9.2 changes
[2] Other similar problems:
-
Mozilla 1.7: nsIDOMSerializer
- XULRunner 1.8: nsIFilePicker
- XULRunner
1.8: nsIHelperAppLauncher
- XULRunner 1.8: nsIProgressDialog
- XULRunner
1.9: nsICookieService
- XULRunner 1.9.1: nsIScriptSecurityManager
[3]
Changes in native behaviour:
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=214807 : xulrunner 1.9 has changed invalid certificate behaviour
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=259687 : _javascript_ executes asynchronously with xulrunner 1.9
[4]
Suggested workarounds for XULRunner, and why they did not meet our
requirements:
i. Suggestion: Only use frozen interfaces.
- The Browser
cannot do this without providing significantly less functionality than is needed
to fulfill its responsibilities.
ii. Suggestion: Don't use nsIDocShell
anymore.
- This change was made in Eclipse/SWT 3.5. However, this does not
help with the various other unfrozen interfaces currently being
used.
iii. Suggestion: Specify the maxversion more tightly when
auto-detecting a native browser to use.
- This could avoid some crashes, but
would result in no native browser being found for use on newer Linux distros.
Since having a working Browser control on Linux is essential, this is not an
adequate solution.
iv. Suggestion: Ship XULRunner, "treating Mozilla as a
system library is pain and hurt"
- This has been reported to have limited
success since the back-end API needs of XULRunner are diverse, and unsatisfied
shared library dependencies can still occur. A native browser that is properly
integrated with the target OS is needed.
v.Suggestion: Make XPCOM calls
via _javascript_
- This could alleviate some problems related to member
positioning within a class, but would not have helped other breakages, such
as:
- nsIHelperAppLauncherDialog.PromptForSaveToFile() (the Browser
implements this interface):
- grew an argument in Mozilla 1.5
- changed an
argument type in XULRunner 1.8
- grew another argument in XULRunner 1.9
-
nsIDOMSerializer.SerializeToString() changed an argument type in Mozilla
1.7
- nsIFilePicker.Init() and nsIFilePicker.SetDefaultString() changed their
argument types in XULRunner 1.8 (the Browser implements this interface)
-
nsIDownload changed significantly (>10 method signatures) in XULRunner 1.8
(the Browser implements this interface)
- the contractID for registering a
download factory changed in XULRunner 1.8
- the XULRunner 1.9 behavioral
breakages in [3]
_______________________________________________
eclipse-pmc
mailing list
eclipse-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-pmc
_______________________________________________
eclipse-pmc mailing
list
eclipse-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-pmc