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

Consider changing the way in which BrowserSim uses WebKit engine ---------------------------------------------------------------- Key: JBIDE-13364 URL: https://issues.redhat.com/browse/JBIDE-13364 Project: Tools (JBoss Tools) Issue Type: Feature Request Components: browsersim Reporter: Yahor Radtsevich Assignee: Ilya Buziuk Priority: Major Fix For: 4.16.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&a...] ** ? 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).