[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-pmc] On using WebKitGTK
|
+1!
Dani
|------------>
| From: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Mike Wilson <Mike_Wilson@xxxxxxxxxx> |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|eclipse-pmc@xxxxxxxxxxx |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|16.03.2010 21:45 |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|[eclipse-pmc] On using WebKitGTK |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
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.
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.
c) The functionality, usability or consumability of the Eclipse project
would be severely restricted or reduced without the APIs.
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 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
