[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [eclipse-pmc] On using WebKitGTK
|
Ok, the new words are below, and they
should include everyone's feedback. I've also added two sentences
towards the bottom (not a footnote) with a link to the mozilla.org bug
report requesting interfaces to be frozen.
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 Project requests approval to require WebKitGTK under the LGPL because
it addresses critical community needs.
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) [Pre-Req] 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) [No Alternative] 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) [Severity] 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 regard,
the PMC (with the help of our browser guru, Grant Gayed) investigated and
determined the following w.r.t. the above points:
a) [Pre-Req] 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).
b) [No Alternative] 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) [Severity] 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.
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 has
caused SWT's Browser control on Linux to become less- functional or non-functional,
and we have been forced to adapt it to the native-level XULRunner changes
in 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].
A Mozilla bug report (https://bugzilla.mozilla.org/show_bug.cgi?id=248683)
requesting that interfaces used by the Browser control become frozen was
never resolved (some of the interfaces have subsequently become frozen
but others have not). In the meantime, the Browser has grown to rely
on 28 unfrozen interfaces in order to fulfill its responsibilities.
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 behavioural
breakages in [3]
"Oberhuber, Martin"
<Martin.Oberhuber@xxxxxxxxxxxxx>
Sent by: eclipse-pmc-bounces@xxxxxxxxxxx
03/17/10 02:51 AM
Please respond to
eclipse-pmc@xxxxxxxxxxx |
|
To
| <eclipse-pmc@xxxxxxxxxxx>
|
cc
|
|
Subject
| RE: [eclipse-pmc] On using WebKitGTK |
|
+1 on the proposal. Great work!
Regarding Jeff's proposal, the
wording "reship WebKitGTK" is confusing. We are talking about
a pre-req here. All we are going to ship is Java +JNI code that's supposed
to link dynamically to the WebKitGTK sharedlibs which are expected to be
pre-installed. Or did I miss the point here?
I agree that the answers to a/b/c
could better relate to the requirements a/b/c. Rather than in-lining with
the requirements, it could also work to re-phrase the req at the beginning
of the answer, e.g. a) Pre-req: ....
On section [4] suggested workarounds,
I'm missing a statement that we tried to work with the Mozilla Foundation
on freezing the APIs that we need, and what their take was.
Martin
From: eclipse-pmc-bounces@xxxxxxxxxxx
[mailto:eclipse-pmc-bounces@xxxxxxxxxxx] On Behalf Of Jeff McAffer
Sent: Wednesday, March 17, 2010 2:49 AM
To: eclipse-pmc@xxxxxxxxxxx
Subject: Re: [eclipse-pmc] On using WebKitGTK
+1
Awesome! Likely the most well researched proposal
ever at Eclipse. A couple small tweaks
- Suggest putting a line at the beginning somewhere saying
that "The Eclipse Project requests approval to reship WebKitGTK under
the LGPL because is addresses critical community needs." Then launch
into the whole story.
- "to help in this disregard" --> "to
help in this *regard*"
- suggest trimming the answers to a, b, c and putting
them with the points. See below. The idea is to give board members something
they can easily parse and understand (they don't know the ins and outs
of this stuff). If they want more info they can read on.
Anyway, just a suggestion.
Jeff
On 2010-03-16, at 4:45 PM, Mike Wilson wrote:
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