Skip to main content
chris.campbell
Community Manager
Community Manager
June 11, 2014
Question

How do you use AIR's WebKit/htmlloader?

  • June 11, 2014
  • 74 replies
  • 41371 views

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

This topic has been closed for replies.

74 replies

Participant
March 25, 2015

I use Htmlloader for hybrid with as3 displayobjects.  I intensively use jquery, and other javascript libraries to build epub reader.

Even if Htmlloader does not support <video> tag, this way, at least can replace to custom video player by tracking html element's bounding rects.

My current biggest unsolvable problem is HTMLLoader's poor crappy rendering.

Since retina display is now widely spread all over, people's expectation on visual experience extremely high compare to before.

One thing that I can't not bear is that there's nothing I can do about it, such as showing crisp font rendering as other native platform does.

Decision makers in company they don't care why it is not possible to show crisp font rendering, but they just keep asking whether I'm capable to do it or not.

Any solution or any updates on roadmap when it can be done?  I just need to show HTMLLoader text and image as clear as native app.

FYI, rendering comparison between HTMLLoader and Safari. (using css and ttf font)

Participating Frequently
March 17, 2015

The first positive sign that Adobe might actually be doing something about this:

"AIR – Improved HTML5 support" has been added to the road map under New Features section for 2015 and beyond

Adobe roadmap for the Flash runtimes | Adobe Developer Connection

Lets hope it arrives sooner rather than later. "AIR – 64-bit support for Windows and Mac applications" is also pretty exciting.

Participant
January 22, 2015

Hi Chris, as we use Adobe AIR to build cross platform (enterprise) applications, using the system's web browser is not an option (we don't use it because of that). If the whole app is cross platform except the HTML browser it kinda defeats the point of 'cross platform'.

Cheers, Willem-Paul

Participating Frequently
January 13, 2015

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

chris.campbell
Community Manager
Community Manager
January 14, 2015

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.

January 14, 2015

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

Inspiring
January 11, 2015

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

January 11, 2015

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?

Participating Frequently
November 27, 2014

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
Inspiring
November 27, 2014

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

Participant
November 26, 2014

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-air-webkit-v6531-9-webvi

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

Participant
November 26, 2014

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.

Participant
November 20, 2014

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

Participant
November 14, 2014

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.