How do you use AIR's WebKit/htmlloader?

[chris.campbell]

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

[Born2code]

yes thanks...

regards

[Ylazy]

Great news... thanks!

[LeadBaxter]

Hi gperrry91, where did you see that quote from Chris yesterday (as of your post on 6/9/2016)? I'm looking and I can't find it.

I'm new to the issue, but very interested in the outcome!

[Colin Holgate]

It's here: Re: Any solution planned yet for upgrading WebKit / HTML engine in AIR 23?

[LeadBaxter]

How very helpful for you to post that link... Not only because it answers my question, but because it leads to what is apparently the continuation of this discussion!

Thank you!

[Colin Holgate]

Fresh start for you!

[goldysilva]

Thank you Chris ... Highly appreciated

[bfoster-cl]

Thanks Chris, I'm eagerly awaiting some (hopefully) good news

[Brian_ONE]

I need communication between AS and JS.  That is critical.  I think the best solution would be allow the developer to select the version of WebKit DLL they would like to use, and that would link the correct library at built time.  Download size is not an issue for most these days, with brodband connections common for most desktop users.  The WebKit in AIR 15 is from 2010 - it's almost 5 years old!

If Adobe cannot or will not address this issue please let the community help somehow.  This has gone on for way to long, and we deserve the ability to solve this issue.

[mikarr]

Hi Chris,

Our AIR apps make extensive use of HTML components that need to function and render identically across all desktop platforms, so we use HTMLLoader and write HTML+JS specifically targeted to AIR's WebKit.

Therefore StageWebView (even with JS interoperability) is not an option for us, as there is no way to guarantee uniform functionality and rendering with users having different browsers and browser versions installed.

We would very much like to see an updated WebKit as soon as possible, though, even if for no other reason than resolving incident id 184198649 (rendering glitches on Windows when using CSS zoom).

So our requirements are:

• keep HTMLLoader as it is
• update the included WebKit

Making it optional to bundle WebKit into your app, so those who don't need it can save space, also seems a great suggestion.

Thanks,

  Mika

[dlldlldlldll]

I took a quick searched on, to see the possibility of updating the webkit of adobe air, and found some interesting links, just now find some skilful programmer to make this update, since this adobe not giving a damn for it.

One thing I noticed also is that Adobe Muse was developed in Adobe Air, and now uses the built-in adobe air, and the interesting thing is that the file "WebKit.dll" is different from standard air adobe installation, ie was up to date.

http://stackoverflow.com/questions/10906652/possible-to-replace-slow-and-html5-incompliant-adobes-ai...

http://www.kurilo.su/webkit/webkit.7z

http://www.kurilo.su/webkit/webkit_pack.7z

https://github.com/DKurilo/AirWebKit

https://wikidocs.adobe.com/wiki/pages/viewpage.action?pageId=78774573

http://sourceforge.net/adobe/adobe-webkit/home/WebKit%20and%20Adobe%20Contributions/

https://github.com/adobe-flash/Webkit4AIR

http://trac.webkit.org/wiki/ApolloWebKit

[bfoster-cl]

Thanks for the links. Muse used to built in AIR but they recently re-wrote it as a native 64bit app. I wonder how much of the decision to rewrite was based on the outdated WebKit, and Adobe's lack of commitment to AIR. One of the first new first features to arrive after the rewrite was SVG support which is desperately needed in AIR WebKit.

[goldysilva]

Hey Chris, so dlldlldlldll wrote: "One thing I noticed also is that Adobe Muse was developed in Adobe Air, and now uses the built-in adobe air, and the interesting thing is that the file "WebKit.dll" is different from standard air adobe installation, ie was up to date."

If this is true, what is the deal... Is there a now private version of Air (used to create Muse) that we can expect to be made public?

[Colin Holgate]

Muse had a major rewrite for the June release. I think it may not be AIR based anymore.

[Guest]

I know previous posts have asked this question but it has been several months, but are there any updates on this? Or can you at least share the direction your team is looking at going if nothing has been done yet?

[Neverbirth]

It would be nice if new AIR versions would use WKWebView when using StageWebView in iOS8 or later: http://t.co/19UxrpjdOz

[mpguerin]

Chris, can we please have an update on this? Will we ever see updated support in AIR for HTML5, SVG etc?

[chris.campbell]

I don't have an update yet, but it's been on my mind since this discussion started.  I think it's pretty safe to say that we won't be updating the existing WebKit, but I think finding other solutions is something we need to think very hard about.  It's clear that there is a need here.

[Guest]

Thank you for providing a status update. It is much appreciated.

[flashdictionary]

Thank you for the update Chris, I believe that answers many questions right now. I will make some predictions and guestimations for everybody here to satisfy my own curiosities and have a little fun.

Today the latest Flash Player and AIR SDK was released.

• This is the first release that includes the new iOS compiler with 64-bit support, but there are still known issues with it, so I would guess that Adobe needs at least a month to polish off this work.
• iOS8 support still isnt finished yet, still need iOS simulator, screen rotations, launch images, and probably some other things. So I would guess this will also take a month.
• Adobe is still working on concurrency, and I am glad to see more progress on this: [AIR Desktop]AIR Runtime crashes when using worker feature in a complex application.(3841682). Many people haven't been able to use workers on Desktops or Androids because it constantly crashes. Concurrency is probably getting close to finished on Desktop with this release, although the MessageChannel still has some kinks to work out. This probably means that concurrency on iOS will appear within a month after finishing iOS compiler and iOS8 support. So maybe 3 months away until concurrency is usable.
• I will guess that a new roadmap from Chris is at least 2-3 months away. I don't think that they can give an updated roadmap until they know how much longer it will take to get iOS8 support finished and concurrency.
• VideoTexture is in my opinion one of the best features that Adobe is working on, and a smart move. Today's release notes indicate the fix for CNN video size, first frame being lost, and fixing the tightly coupled hardware acceleration issue. So it appears that more of the video logic has been decoupled, but more decoupling needs to be done. StageVideo with automatic software failover means that much of the decoupling has been completed at least on Desktop machines. On Androids there are some significant challenges due to all of the existing StageVideo bugs and GPU vs Direct technical debts, so I would guess that VideoTexture support will be seen on iOS before Android, or it will be more stable on iOS than it is on Android. I sure hope that VideoTexture on iOS will support H264 and Nellymoser, because it not, then I am getting my hopes up for nothing. So lets say that VideoTexture is probably 2 months away from full desktop support, and 5 months away from mobile support.
• ASC2.0 still has glitches with the Inline and compiler optimizations, but it appears to be working as long as you don't use the inline feature. I would guess that Adobe will not spend any more time on ASC2.0 compiler optimizations this year, but in the 3rd quarter they might fix the inline feature.
• In the 4th quarter of 2015 I hope that VideoTexture will support WebRTC. If not, I am sure a few ANEs will pop up and do a WebRTC overlay, but it would be much smarter to get it supported so that it can be integrated into Stage3D.
• Now, finally, as for the HTMLLoader, that class is not going to change. It will remain with the old WebKit unfortunately. But I bet that before the last quarter of the year 2015, the Adobe AIR team will add JavaScript interoperability to the StageWebView class.

I hope that Adobe will increase the funding for the AIR SDK. I also hope that Chris's team will prove that these guestimates are overestimated. Oh, one last thought...(I bet that the Adobe AIR runtime and SDK intellectual property will be bought out in 2016)

[Harry248]

Chris, please at least give StageWebView some love:

- Touch / gesture detection (currently we are not even able to detect a touch on it !!!)

- More configuration options (e.g. set background color, enable/disable zoom, bounce effect, etc.)

- Support for AirPrint

And fix nasty bugs like these:

Bug#3532211 - StageWebView loses interactivity in Android following Event.DEACTIVATE, Event.ACTIVATE

Bug#3362483 - LocationChangeEvent LOCATION_CHANGING does not fire for javascript based events

[Muzak]

> I think it's pretty safe to say that we won't be updating the existing WebKit

If that is the case and it is not replaced by something better - and not StageWebView - then I'm out.

By the way, fun fact:

Create a new AIR project. Add a HTML control. Set the location to "http://adobe.com".. Have fun with that one.

[Indyaner]

Any Updates on this topic?

I'm currently in the progress of including StageWebView into my project, but I kinda hesitate because of the Limitations that really irks me:

- Cant have overlays

- Sitting as seperated instance on stage

- Size only defineable by rect()

- Limited JS support (half of my jquery plugins wer not displayed anyways)

- No External Interface.

Either I go and knit myself something aweful or Chris comes around the corner with a kickass DisplayObject-Solution with massive Event-Dispatchers and a good rendering Engine

Thanks

Indy

[chris.campbell]

Nothing yet, but internal discussions are definitely happening.  I'm hoping to have follow up questions and clarifications in the coming weeks.

[Guest]

Hi Chris, I was wondering if you had any news to share. I work at an ad agency firm, and a few years ago, I built an AIR app to take screenshots of the emails we create for our internal review process. With Chrome, starting Sept 1 this year, having Flash Player movies in websites being click-to-play by default, we are starting to switch to building HTML5 ad banners instead of Flash banners if they will run past that point. I was hoping to build another app in AIR to take screenshots of the banners we create (since it would speed up our development process than having to take a screenshot of the browser window and then take into Photoshop to remove the window chrome). But because AIR's webkit version only has minimal support for CSS3 and HTML5, I currently can't do that. Been looking into other options, such as html2canvas, but being in the browser, my options for that being a solution are not pretty.

So any info on progress or at least the decisions being made on what direction your team is planning on taking that you can provide for everyone here would be awesome. Thank you.