How do you use AIR's WebKit/htmlloader?

Question

Hi everyone,
A long standing issue in AIR has been the inclusion of an older version of WebKit.  The request to update this library has come up many times in the forum and is in the top 10 on the community driven Uplist feature page.  As with the recent and ongoing physics discussion, we're not committing to any changes purposed below at this time,  as we're purely in an investigation mode at this time.  We realize that this is an important feature and we need further clarification on what you're looking for.  Please read on for questions from our development team.
We are exploring updating WebKit, but due to our modification of the WebKit source, this will be difficult, and updating WebKit will change the HTML DOM, possibly breaking content authored for our existing DOM.
So we are also exploring leaving HTMLLoader alone, for now, but providing a reasonable alternative.
StageWebView was originally written as a replacement for HTMLLoader on mobile (because we could not use our WebKit on mobile, StageWebView took advantage of the browser provided by the platform).
But it was extended to the desktop as an unsuccessful solution to this problem.
On mobile, content was probably newly written (so it could be tested with StageWebView), and the browsers were similar enough to our WebKit that the DOM impact was minor.
But on the desktop, forcing older content written for our WebKit to run on Internet Explorer 8 (as an example) was a disaster due to the differences in the DOM’s. We resolved this by making HTMLLoader versus StageWebView on the desktop a choice.
Which gets to the questions (for desktop development only).
Which is more attractive, an embedded web browser or using the system browser? Is it valuable to provide both?
For instance, using the native browser can save on code size (perhaps 6 MB), but you must create and test portable HTML, and you face the risk that future updates to the system browser breaks your content.
How much interop do you need between AS and JS?
Hearsay suggests another problem with StageWebView is there is no interop between ActionScript and JavaScript, whereas HTMLLoader had a lot of support.
Would StageWebView be sufficient if it exposed an ExternalInterface, or sandbox bridge, level of functionality? For instance, if AS could register a list of functions which could be called from JS (and vice versa), would that be enough? Or is there something else that HTMLLoader does that is essential?
For instance, one of the ideas being explored is to provide an entirely new class (perhaps as an ANE) which links an unmodified version of the latest WebKit source as a static library. By using unmodified source, we can more readily update to newer versions of WebKit.  As well, if we leave the existing classes unchanged, we don’t risk breaking existing content. But if we use unmodified WebKit source, we may find some of HTMLLoader’s functionality impossible to match, which is why I’m interested in understanding the essential functionality, so we can decide if a sufficient, minimal (so it’s easier to support without customizing Webkit) interface for it.
Thanks,
Chris

Answer 1

Hey Chris,
Thank you for reaching out to the community! Our team has been working on AIR apps for a while now. It has been frustrating to say the least, trying to integrate sophisticated HTML5 apps into our different AIR apps.
The existing solutions on mobile and desktop are not very satisfying. Mobile has gotten better because of the StageWebView, but there are still several flaws that make the platform unpredictable. On desktop it is even worse and we are facing a tough decision.
We want to integrate an HTML5 app into an already existing AIR app. The two applications will have to communicate in some form with each other. The StageWebView approach with a simple ExternalInterface would suffice, as long as we could pick from the browsers that are installed. The ANE class approach also sounds good, but only if there is a similar way of communication.
We think that keeping the component (WebView or ANE class) as lean as possible is one of the most important things. We don't want to face the same issues in the near future. There is also a need to update that underlying layer fast. Browser vendors (with some exceptions of course ) have much faster release cycles nowadays. They will keep pushing the boundaries and we need to adjust accordingly.
The HTML5/JS should take care of the DOM manipulation, event handling and communicate back to Actionscript in a simple way. There is no need for Actionscript to worry about these things. And if there is, create a simple JS layer using the interface to do the job.
Here is a list of features that are essential to us:
Accessing the local file system (xhr requests on the local file system):
Worst case scenario: Using the ExternalInterface to feed files to the HTML application.
Configure the cache or at least manipulate cache handling
Much better HTML5 / CSS3 support: Video, Audio, SVG, CSS3 Animations, etc.
Easier and faster way to update the underlying WebKit/Chromium (relevant for ANE)
Are there any plans yet? Is it on your roadmap? Are we talking about years or months? Answers to these questions are very crucial for us. Only with those answers will we know, whether we can keep working on the AIR platform or if we have to look for alternatives and migrate our entire application.
We are looking forward to your answers.
Thanks