[jbosstools-issues] [JBoss JIRA] (JBIDE-13364) Consider changing the way in which BrowserSim uses WebKit engine

Yahor Radtsevich (JIRA) jira-events at lists.jboss.org
Wed Jan 16 08:24:21 EST 2013 

     [ https://issues.jboss.org/browse/JBIDE-13364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yahor Radtsevich updated JBIDE-13364:
-------------------------------------

    Description: 
A perfect solution for BrowserSim must match the following criteria:
* Be Java-based
* Allow to fully customize the application window [skinning]
* Work on every supported platform (Windows, Mac and Linux)
* Use browser already installed in the system [to avoid library conflicts and reduce the size of our plugins]
* Allow to execute JavaScript and/or modify DOM [to simulate some mobile * JavaScript events and Cordova API]
* Allow to change User-Agent header
* Allow to disable web security or support extensions [for Cordova cross-domain requests]
* Support debugging protocol or support extensions [for better LiveEdit/LiveReload]
* Support debugging protocol or ability to launch Web Inspector/Chrome Developer Tools [for JavaScript debugging capabilities]

Unfortunately, there is no perfect solution, at least I do not know any.
This is the list of the libraries I consider for BrowserSim (+=Pros, -=Cons, ?=questionable):
* Java wrapper for [Chromium Embedded Framework|http://code.google.com/p/javachromiumembedded/]
** + I was able to run it on Windows
** - It failed in a half of a minute :)
** - Not supported since 2010
** ? probably will work better with the most recent version of CEF
** ? looks like there is no Linux support
* [Qt WebKit bindings for SWT|http://code.google.com/p/qtwidgetsinswt/]
** + I was able successfully run on Windows (32-bit) with Qt 4.8 and MinGW
** + At least during my smoketesting it did not fail
** - The plugin page claims that only win32 and cocoa32 are supported
** - requires Qt (and MSVC or MinGW for Windows) libraries to be bundled with it
** - Does not have existing API for invoking JavaScript.
** - Not supported since 2010
** ? I do not know how easy it would be to run it on Linux
** ? I do not know if it will work with Qt 5
* [AppJS|http://appjs.org/] - a JavaScript SDK for creating Chromium based desktop applications
** + Supports Windows, Mac and Linux!
** + Allows to disable web security
** + Has active community
** + Did not fail at my smoketest
** ? need to ensure that applications may be run without borders
* [node-webkit|https://github.com/rogerwang/node-webkit#readme] - the idea is the same as with AppJS - allows to create desktop apps with JavaScript
** + supported by Intel in some way
** ? I did not try it yet
* [Google Chrome Frame|http://www.google.com/chromeframe]
** + the only way to embed _already installed_ Chrome into our application (all other require libraries to be bundled)
** - Windows only
** - [no success to use it as Ole object|http://code.google.com/p/chromium/issues/attachmentText?id=25448&aid=7270863545245289566&name=JavaChromeIntegration.java]
** ? Probably will work if use it with Browser(SWT.NONE)
* Stay with existing SWT bindings for WebKit
** + We already use it
** + Support all platforms
** + Allow JavaScript to be executed
** + Do not require to be bundled with our plugins
** + Allow skinning
** - Require Safari on Windows [no updates since May 9, 2012]
** - Web security cannot be disabled
** - Do not support extensions
** - Do not support remote debugging protocol
** - Do not support Web Inspector/Chrome Developer Tools

*To conclude:*
* Firstly, moving to a JavaScript SDK potentially could resolve all our problems, but now I do not think it is worth it.
* Secondly, it would be great if we had good SWT bindings for Chromium, but they do not exist. The only way to get them is to implement them by ourself.
* Thirdly, the last option does not look too bad. And probably it does not worth it to create Chromium bindings or to move to another non-Java language. Especially, if we would be able to create a good workaround for cross-domain requests for Cordova, then almost everything else is ok.
* Fourthly, the biggest issue with existing SWT bindings is that Safari is not supported anymore on Windows. It is an OS specific issue and we could consider a replacement of SWT bindings on Windows only (e.g. use Chrome Frame or Qt on Windows).

  was:
A perfect solution for BrowserSim must match the following criteria:
* Be Java-based
* Allow to fully customize the application window [skinning]
* Work on every supported platform (Windows, Mac and Linux)
* Use browser already installed in the system [to avoid library conflicts and reduce the size of our plugins]
* Allow to execute JavaScript and/or modify DOM [to simulate some mobile * JavaScript events and Cordova API]
* Allow to change User-Agent header
* Allow to disable web security or support extensions [for Cordova cross-domain requests]
* Support debugging protocol or support extensions [for better LiveEdit/LiveReload and JavaScript debugging capabilities]

Unfortunately, there is no perfect solution, at least I do not know any.
This is the list of the libraries I consider for BrowserSim (+=Pros, -=Cons, ?=questionable):
* Java wrapper for [Chromium Embedded Framework|http://code.google.com/p/javachromiumembedded/]
** + I was able to run it on Windows
** - It failed in a half of a minute :)
** - Not supported since 2010
** ? probably will work better with the most recent version of CEF
** ? looks like there is no Linux support
* [Qt WebKit bindings for SWT|http://code.google.com/p/qtwidgetsinswt/]
** + I was able successfully run on Windows (32-bit) with Qt 4.8 and MinGW
** + At least during my smoketesting it did not fail
** - The plugin page claims that only win32 and cocoa32 are supported
** - requires Qt (and MSVC or MinGW for Windows) libraries to be bundled with it
** - Does not have existing API for invoking JavaScript.
** - Not supported since 2010
** ? I do not know how easy it would be to run it on Linux
** ? I do not know if it will work with Qt 5
* [AppJS|http://appjs.org/] - a JavaScript SDK for creating Chromium based desktop applications
** + Supports Windows, Mac and Linux!
** + Allows to disable web security
** + Has active community
** + Did not fail at my smoketest
** ? need to ensure that applications may be run without borders
* [node-webkit|https://github.com/rogerwang/node-webkit#readme] - the idea is the same as with AppJS - allows to create desktop apps with JavaScript
** + supported by Intel in some way
** ? I did not try it yet
* [Google Chrome Frame|http://www.google.com/chromeframe]
** + the only way to embed _already installed_ Chrome into our application (all other require libraries to be bundled)
** - Windows only
** - [no success to use it as Ole object|http://code.google.com/p/chromium/issues/attachmentText?id=25448&aid=7270863545245289566&name=JavaChromeIntegration.java]
** ? Probably will work if use it with Browser(SWT.NONE)
* Stay with existing SWT bindings for WebKit
** + We already use it
** + Support all platforms
** + Allow JavaScript to be executed
** + Do not require to be bundled with our plugins
** + Allow skinning
** - Require Safari on Windows [no updates since May 9, 2012]
** - Web security cannot be disabled
** - Do not support extensions
** - Do not support remote debugging protocol

*To conclude:*
* Firstly, moving to a JavaScript SDK potentially could resolve all our problems, but now I do not think it is worth it.
* Secondly, it would be great if we had good SWT bindings for Chromium, but they do not exist. The only way to get them is to implement them by ourself.
* Thirdly, the last option does not look too bad. And probably it does not worth it to create Chromium bindings or to move to another non-Java language. Especially, if we would be able to create a good workaround for cross-domain requests for Cordova, then almost everything else is ok.
* Fourthly, the biggest issue with existing SWT bindings is that Safari is not supported anymore on Windows. It is an OS specific issue and we could consider a replacement of SWT bindings on Windows only (e.g. use Chrome Frame or Qt on Windows).



Agree about Web Inspector/Chrome Developer Tools. Added it to the list.

Note that in the case of Chromium/Chrome based engine the support of debugging protocol implies that Chrome Developer Tools will work automatically (by pointing a WebKit browser to localhost:DEBUGGING_PORT) [1].

[1] https://developers.google.com/chrome-developer-tools/docs/remote-debugging
                
> Consider changing the way in which BrowserSim uses WebKit engine
> ----------------------------------------------------------------
>
>                 Key: JBIDE-13364
>                 URL: https://issues.jboss.org/browse/JBIDE-13364
>             Project: Tools (JBoss Tools)
>          Issue Type: Feature Request
>          Components: Visual Page Editor core
>            Reporter: Yahor Radtsevich
>            Assignee: Yahor Radtsevich
>             Fix For: 4.1.x
>
>
> A perfect solution for BrowserSim must match the following criteria:
> * Be Java-based
> * Allow to fully customize the application window [skinning]
> * Work on every supported platform (Windows, Mac and Linux)
> * Use browser already installed in the system [to avoid library conflicts and reduce the size of our plugins]
> * Allow to execute JavaScript and/or modify DOM [to simulate some mobile * JavaScript events and Cordova API]
> * Allow to change User-Agent header
> * Allow to disable web security or support extensions [for Cordova cross-domain requests]
> * Support debugging protocol or support extensions [for better LiveEdit/LiveReload]
> * Support debugging protocol or ability to launch Web Inspector/Chrome Developer Tools [for JavaScript debugging capabilities]
> Unfortunately, there is no perfect solution, at least I do not know any.
> This is the list of the libraries I consider for BrowserSim (+=Pros, -=Cons, ?=questionable):
> * Java wrapper for [Chromium Embedded Framework|http://code.google.com/p/javachromiumembedded/]
> ** + I was able to run it on Windows
> ** - It failed in a half of a minute :)
> ** - Not supported since 2010
> ** ? probably will work better with the most recent version of CEF
> ** ? looks like there is no Linux support
> * [Qt WebKit bindings for SWT|http://code.google.com/p/qtwidgetsinswt/]
> ** + I was able successfully run on Windows (32-bit) with Qt 4.8 and MinGW
> ** + At least during my smoketesting it did not fail
> ** - The plugin page claims that only win32 and cocoa32 are supported
> ** - requires Qt (and MSVC or MinGW for Windows) libraries to be bundled with it
> ** - Does not have existing API for invoking JavaScript.
> ** - Not supported since 2010
> ** ? I do not know how easy it would be to run it on Linux
> ** ? I do not know if it will work with Qt 5
> * [AppJS|http://appjs.org/] - a JavaScript SDK for creating Chromium based desktop applications
> ** + Supports Windows, Mac and Linux!
> ** + Allows to disable web security
> ** + Has active community
> ** + Did not fail at my smoketest
> ** ? need to ensure that applications may be run without borders
> * [node-webkit|https://github.com/rogerwang/node-webkit#readme] - the idea is the same as with AppJS - allows to create desktop apps with JavaScript
> ** + supported by Intel in some way
> ** ? I did not try it yet
> * [Google Chrome Frame|http://www.google.com/chromeframe]
> ** + the only way to embed _already installed_ Chrome into our application (all other require libraries to be bundled)
> ** - Windows only
> ** - [no success to use it as Ole object|http://code.google.com/p/chromium/issues/attachmentText?id=25448&aid=7270863545245289566&name=JavaChromeIntegration.java]
> ** ? Probably will work if use it with Browser(SWT.NONE)
> * Stay with existing SWT bindings for WebKit
> ** + We already use it
> ** + Support all platforms
> ** + Allow JavaScript to be executed
> ** + Do not require to be bundled with our plugins
> ** + Allow skinning
> ** - Require Safari on Windows [no updates since May 9, 2012]
> ** - Web security cannot be disabled
> ** - Do not support extensions
> ** - Do not support remote debugging protocol
> ** - Do not support Web Inspector/Chrome Developer Tools
> *To conclude:*
> * Firstly, moving to a JavaScript SDK potentially could resolve all our problems, but now I do not think it is worth it.
> * Secondly, it would be great if we had good SWT bindings for Chromium, but they do not exist. The only way to get them is to implement them by ourself.
> * Thirdly, the last option does not look too bad. And probably it does not worth it to create Chromium bindings or to move to another non-Java language. Especially, if we would be able to create a good workaround for cross-domain requests for Cordova, then almost everything else is ok.
> * Fourthly, the biggest issue with existing SWT bindings is that Safari is not supported anymore on Windows. It is an OS specific issue and we could consider a replacement of SWT bindings on Windows only (e.g. use Chrome Frame or Qt on Windows).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

More information about the jbosstools-issues mailing list