From: eclipse-pmc-bounces@xxxxxxxxxxx
[mailto:eclipse-pmc-bounces@xxxxxxxxxxx] On Behalf Of Grant Gayed
Sent: March-18-10 1:06 PM
To: eclipse-pmc@xxxxxxxxxxx
Subject: 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