How do you use AIR's WebKit/htmlloader?

For what little I do with the HTMLLoader object, just being on the latest version of Webkit so I can have HTML5 video and audio would be enough for me. I also heavily use the events that HTMLLoader offers to make state changes to AS UI elements. On the concern of updating the DOM breaking existing content, correct me if Im wrong but it would only have the potential to break in an app if the app was updated/re-published. Hope this was helpful.

Edit: Also, just want to say thank you for considering updates and asking the community what we would like to see.

Pretty much every time I've used HTMLLoader, I've needed to do HTML manipulation using ActionScript. So js to as interop is pretty important to me.

I agree that it makes sense to at least consider chromium and possible CEF. The idea of combining AIR and CEF capabilities sounds like an interesting one to me, although I'm not sure off-hand how I'd use that.

Harbs

Hi Chris

We currently use the mx:HTML object in our desktop AIR application to load in a variety of web content. Some of this content we generate ourselves contains links which we capture using the locationChange handler and feed into the application to make various bits of the application work.

override protected function htmlLoader_locationChangeHandler(event:Event):void
  {
  if(htmlLoader.location && LinkUtils.doWeHaveAValidURLLink(htmlLoader.location))
  {
  event.preventDefault();
  LinkUtils.actionValidURLLink(htmlLoader.location);
  // set the location back to the one used before so the same bug link can be 
  // clicked twice in a row and this function still gets called.
  htmlLoader.loadString(htmlText);
  }
  else
  {
  super.htmlLoader_locationChangeHandler(event);
  }
  }

Key things we'd require for our application to continue to work are as follows:-

1) Access to a locationChange/locationChanged handler (We had to make the handler protected from private to enable our code to work as required)

2) Capacity to pass an HTML string containing the markup to display, rather than pointing the component to a URL.

3) Access to the internal htmlLoader  to call the loadString() method, or similar.

Desirable features for a new WebKit/HTML:-

1) SVG Graphics

2) HTML5 Audio/Video

3) Proper displaylist support.

4) Access to complete handler for page loading completion.

Getting support for HTML5, Video and better rendering of modern web pages is huge for my team and our application. I'd be willing to participate in any testing or beta programme that Adobe would offer here.

Thanks,

Marc

1. Support for osx retina display

Currently, I use HTMLLoader to implement hybrid Flash/HTML desktop application, and even configuring the descriptors files correctly, the HTML content will be rendered in compatibility mode (upscaled 2x) - it is very noticeable alongside with the Flash-based content renderered in native resolution.

2. Improve HTML5 compatibility

Many authoring applications (e.g. Articulate) are able to create HTML5 packages, but that content often cannot be rendered by the HTMLLoader, usually due to the lack of support for recent standards, such as WebFonts and SVG rendering. This is especially useful for Learning Management System solutions, or in general when external resources need to be rendered.

Thank you for asking,

Cosma

Updating the embedded Webkit engine would be extremely useful. Also, StageWebView is severely lacking in a lot of areas... you can get an idea by looking at this commercial ANE:

iOS UIWebView and VideoPlayer Native Extension for AIR mobile | Darkredz Studio

It would be a shame to make the author work unneeded, but I think StageWebView should be improved and be on par with its native counterparts.

Hi Chris,

I'll straight up to the point:

1. StageWebView desperately needs two key features:

1.1. Add an autoSnapshot:Boolean property to the StageWebView Class, so that when setting autoSnapshot=true and the StageWebView is not currently interacted by user, StageWebView can automaticly draw its viewport to BitmapData, and automaticly add the Bitmap to DisplayList, in the meantime automaticly hide the true webpage view. This feature will make our jobs way more easier than before!

1.2 Add ExternalInterface support to StageWebView.

2. About the AIR's WebKit, well, I think it just needs to be updated to the latest version of WebKit, the current version is so out of date.

I'm very appreciated to all the great works of Adobe AIR Team, wishing it could go really far

DarkStone

2014-06-12

Hi Chris,

I have my problem/question about using WebKit for desktop AIR project. I don't know if there is any solution exists to my problem, but I'd like to share those thoughts with you regarding WebKit usage in AIR desktop.

As per How to publish your AIR application to Mac App Store (guide) - Pigsels Media , we're packaging desktop AIR application to submit to Apple App Store. The problem comes when we have WebKit usage (HTML) in the application. As per the article, one can not include WebKit classes while packaging for App Store, as Apple would reject the app.

1. Now, it’s time to make the magic: remove webkit.plugin from your bundle. This, of course, means, that you will not be able to use HTML rendering in your AIR application. The reason behind this is that Apple will refuse your app with WebKit plugin in it, because this plugin itself contains calls to undocumented Mac APIs, which is not tolerated by Apple.

Fortunately an AIR application will work just fine without WebKit if it has no use of HTML rendering.

In the kind of cases, WebKit seems not a solution at all. Our .pkg installed executable fail working with HTML component if we removes WebKit while packaging. I am also not sure what if we have StageWebView in place of WebKit component to AIR desktop, maybe we could cut down these complexities in packaging then

Thank you!

StageWebView not only needs some care on desktop. There are a lot of (critical) bugs (like #3572986) in the mobile version too, which should be fixed first before adding new features.

Despite that - absolutely must-haves for a new StageWebView / HTMLLoader:

- bullet-proof HTML5 Audio/Video support

- (easy) JS / AS Interface

- Touch/Gesture recognition (it's a shame that we are not even able to recognize touches on the Webview)

Thanks for listening Chris!

I would love to see the HTMLLoader updated but would be fine with a new HTML object - what is super important for me is the AS-JS integration. My app is tightly integrated with the HTMLLoader with code like the following :

// using jQuery to set element text
_htmlview.window.$("#mydiv").html("some text")

// getting an element's width
var nodeWidth:Number = parseFloat(_htmlview.window.document.getElementById("mydiv").style.width);

or registering its own handlers on an observer in the JS:

_htmlview.window.MyObserver.addListener("elementSelect", onElementSelect);

This allows me integrate with the DOM and draw UI above the HTMLLoader.

As for features I find myself missing:

• SVG
• CSS calc()
• element.classList API
• matchMedia
• HTML5 Audio/Video

What would be good would be to update the HTML loader but also to introduce a standalone library that could load modern web code and be manipulated within the runtime. External interface was nice originally because of the type cohesion between JavaScript and actionscript. So passing objects worked seamlessly etc. My understanding is that it should even be possible to cross compile something like chromium using flascc and actually include it directly in a project as an ABC library. The interface that's written in swig would probably determine the available capabilities. In theory though it would be a game changer to be able to create a browser object that uses latest sources and manipulate it like any other object in actionscript. This would also allow you to use HTML tools like edge along side actionscript in a given application. That is obviously a business value not to mention a way to combine technologies which was the original intention of Adobe's contribution of avm2 for tamarin.