How do you use AIR's WebKit/htmlloader?

Hello Chris,

I agree to replace the internal old webkit with native browser if AIR runtime is going to be small. I'm mainly developing mobile apps with AIR and HTML5. I'm using HTML5/JavaScript for contents and using AIR for user interfaces and logic. But sometimes I face the problem on using StageWebView. For instance, I'd like to use Local Storage on StageWebView. But there is no way to access Local Storage (Web Storage) of StageWebView on Android. (It's possible to access Local Storage on iOS). To enable Local Storage, It is necessary to set the value of setDomStorageEnabled as true by native code.

// webSettings.setDomStorageEnabled(true);

It will be grateful if there are the options to change native browser's setting such as Local Storage.

Any updates on the status of this issue?

I primarily use the HTML control in Adobe AIR for authenticating and granting app permissions for Facebook, Twitter, and other OAuth services. You can do this with StageWebView, but there are problems when the OAuth sign in web page has window javascript calls like window.close() which can shutdown the application, or the move or resize methods. So it would be great if we could override those calls. Easier JS interoperability can help with this, so I can inject js to remove those calls on the page. Other methods I have found to be useful are the changing location, changed location, page loaded, and dom ready events.

It should also be noted that the current AIR HTML control does not work very well with Facebook's new login page. The javascript and animations they use on their login page to allow users to select permissions are not able to run in the AIR HTML control. As of the week, Twitter's OAuth sign in process is no longer able to redirect to the success url in the AIR HTML control - this appears to be a change on Twitter's side.

I'm assuming that ExternalInterface is easy for Chris Campbell & team to implement, while deep AS <-> direct DOM manipulations are much more effort.  If that's not true, ignore this post.  =)

But I honestly don't get why people want deep actionscript integration to the DOM.  Maybe for convenience sake (though traversing XML structures is hardly ever convenient!), but if you can directly call JS via ExternalInterface, what more do you need?  I mean, interact with the DOM the way it's easy, using jQuery (or other js framework), and hook yourself up some JS->AS event bindings like so:

  // FYI - untested pseudocode, but I've used similar:

  static public function js(code:String):* {

    return ExternalInterface.call("eval", code);

  }

  static public function js_bind(selector:String, event:String, func:Function):void {

    ExternalInterface.addCallback(magic_name, func);

    ExternalInterface.call("eval", "$('"+selector+"').bind('"+event+"', fancy_magic_to_call_as_func);");

  }

  // Then just write/call javascript from your AS3:

  js("$('.some_class').css('display', 'none')");

  js_bind(".button", "click", function() { trace('HTML button clicked!') });

FYI, I'll fill in the magic and the unbind cleanup when I have some free time.

Hi Chris,

Thank you for taking care of community requirements.

I'm primary using AIR with starling + feathers to develop apps ! and here are requirments:

- Show googlemaps with StageWebView in starling app

- Play videos Youtube, etc with StageWebView in starling app

a deep integration with stagewebview where we can communicate from as3 to htmlcontent and vice versa is all we need. and it must be crossplatform.

Thanks

What I'd love to see, is an easy way to load local files in StageWebView. There is content that is easier to simply produce in HTML instead of AS3, and being able to bundle that with the app (without any hacks) would be great.

Another feature would be to be able to communicate between JS and AS3.

Chris,

In our view, the embedded WebKit provides a competitive advantage to other HTML engines because of its exactness and consistency across the desktop platforms, and the power to operate with native code on the HTML Elements. In regards to architecting an update, the following are attractive to us:

* Ability to access and manipulate the DOM as ActionScript objects.

* Ability for ActionScript to call document.getElement()... and automate the click of a button, and enter text into a textfield.

* Interoperability and consistency across Windows and Mac OSX. Never have to worry about "browsers" and their versions.

* As a native display object, we can create multiple instances, and we can layer the display as we desire.

Things that we do not care about:

* An ExternalInterface to the JavaScript in StageWebView defeats the whole purpose of the WebKit which is in our minds the consistency and native manipulability.

Architecturally, we hope that Adobe does the following with the WebKit:

* Keep the HTMLLoader class as is. The class is already written, and works the way it was intended, which can still provide value to legacy applications that currently use it.

* If a desktop app has no references to HTMLLoader, and is compiled with captive runtime, then we want the captive runtime to exclude the old WebKit.dll (4,663 KB)

* Add a new class to the runtime (perhaps called WebKitDisplay or WebKitLoader) which contains today's version of WebKit. This new class would provide access to the DOM and the ability to getElements as native ActionScript objects.

* Regarding a new and separate "WebKitDisplay.dll", we want it to be included with the captive runtime only if there are references to it.

Glad to hear that Adobe finally going to update the webkit or proprocionar an effective means of embedding an updated browser in adobe air, the greatest need is that the interaction between AS and JS, and to integrate web content into applications without the need to use native client browser, most of my client use windows, with lamentable internet explorer, so the need to embed an updated browser in Adobe Air

One alternative that I thought to do was use the http://www.awesomium.com/download/ and create from it an ANE.

But I'd rather wait.

What is critical: HTML loader comes with a built-in XSLT-processor.

Please update it to also support EXSLT. This has been done by webkit browsers in the last years.

By this we would have a fully usable XSLT-processor in Adobe Air.

I would generally prefer an updated version of the HTML loader, even if this implies changing the DOM.

(There is still the option of using an older version of the SDK for business critical cases.)

As a general principle: Consistency over configuration.

I don't won't to rely on the user's system configuration to ensure my app is working.

Thank you!

Updating the embedded Webkit engine would be extremely useful.

I agree with FrederickCox. I am also working on a desktop app that needs to have the DOM exposed also a newer version webkit that loads modern sites.

ANE with the ability to update Webkit sounds good. I am not to keen on using the system browser for reasons mentioned by you.

What I think is essential (From FrederickCox)

- locationChanging event (with support for #)

- locationChange event (with support for #)

- complete event (html page loaded)

Also a closer interop between AS and JS. Example getting JS events like mouse click and knowing which DOM element was clicked, image, button, text etc.

Also locationChange event should also happen when a link on the page is clicked and not only when the 'location' property is set.

Also why even have a complex bridge/sandbox system in the new proposed html component? Why cant the developer add in her own security...

Many sites use 3rd party scripts from Google and other places (eg. jQuery from Google loads faster because most likely it was cashed on your machine before), not

being able to load sites that cross script disable some of their functionality.

I have read the other entries and I think most of us want this. Creating applications with AS capabilities and a "real browser" can prove to be very powerful.

Thanks for even considering this.