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

Known Participant
October 25, 2016

I am working with the mx HTML control (HTMLLoader) in a new project. I have provided a lot of feedback in this thread but I would like to add another issue that got me a bit stuck.

There is no way to detect if a page fails to load. We need a HTTPStatusEvent, IOErrorEvent and ProgressEvent on this control so we can provide the user with feedback if the internet connection is lost while we are navigating to a page or uploading an attachment in a HTML page. Currently the HTML control does not respond to any of this. There are many threads on stackoverflow saying we need to listen for the events on htmlLoader.loaderInfo etc.. but none of this works.

Participant
October 10, 2016

It looks like with the September release of AIR version 23, there has been no update to the WebKit.  I, too, was looking for an update to the WebKit to provide at least a modicum of support for HTML 5 features, such as video and audio playback.

This is a handy tool for scoring a browser on its support of HTML 5 features:  HTML5test - How well does your browser support HTML5?

On iOS, the test scores in the high 300s for compatibility.  On desktop, the score is still a piddly 89 when tested in my AIR app.  My company uses AIR to create both mobile and desktop versions of apps for our clients.  Right now, the ability to support HTML 5 content suffers a great disparity between platforms - our product is intended to run identically on both.

Participant
October 10, 2016

We have actually started to create an Adobe Native Extension to integrate WKWebView on both OS X and later iOS. On Windows we will have to use the default browser there, so that will be an interesting experience :-(

The reason we are building this ourselves is we need complete control, in particular focus in and out of the HTML control (we are using it to get a decent HTML editor in our app).

Also tried to add Chromium Embedded Framework as an ANE but that was a bit too much for now (and it added over 200Mb to the size of the app).

Would have been a lot easier if the AIR WebKit was updated...

Known Participant
October 10, 2016

For OSX and Android AIR will use the native built in browser... so as long as you have a newer device, ir should be run with latest rendering engine.

However the real issue (in my opinion) is Windows and Mac as the HTML components uses an obsolete WebKit (very old).

The good news as per Adobe, we should soon see ANE from Adobe for Mac and Windows that will use the latest WebKit, can't wait...

regards

Sean.

Known Participant
September 22, 2016

I've responded in this thread before with my thoughts and requirements. However, I have just started a new version of our internal CRM tool where we are going to force our employees to work inside our CRM system (and not the browser).

Think of it as a Trac/Jira ticketing system (we use Redmine). I have several HTMLLoader instances and perform the following functions with it:

- Loading a page by setting location

- Using locationChanging and locationChange events to alter the UI (so user can not browse to certain pages, or we provide different UX for them)

- Manipulating the contents of the page using the domWindow (getElementsById, getElementsByClassName etc..)

- Manipulating the contents of the page using innerHTML, setting the title property, ..

- Automating user tasks like auto-login by filling in forms and sending them with doc.getElementById("login-form").children[0].submit();

- Fixing a hash issue (not scrolling to correct ID when # is in the URL being loaded) by setting  webview.domWindow.document.location.hash

- Using oncontextmenu and onclick events on the domWindow's body. This way we can prevent the user on doing certain actions and providing a custom context menu in our application.

- Getting selected text from the page using target.ownerDocument.getSelection()

As you can see we need a lot of HTMLLoader's functionality. The application works very well and I'm really pleased with the results but the problems we are facing now are:

- Loading newer websites (HTML5) is not working well (they render badly since the developers don't support such old browsers), so I need to provide a "open page in system browser" option now.

- Drag/drop does not work (user is not able to drop a file on a HTML field like it works in the browser)

- Mouse-over (title tag) is not working like it does in the browser

September 22, 2016

Since this thread is now two years old, my vote at this point is just for updating the internal version of webkit in AIR so that any app built with AIR2(4?) use the latest available version of webkit. I know there were concerns about differences in the current AIR webkit vs the latest available version of webkit would yield different looks for apps that utilizes web pages (or internal HTML files) for handling content sections within an app. I would argue that this is a flawed reason to not just update the internal webkit for a few reasons if that is the single reason that an ANE is the option of choice for the Adobe AIR team. First, any app that loads a real web page through the internet could just be updated on the server in case there were actually any issues that came from it. If it was HTML files included with an app or that were generated with AS3/XML code then the app could be updated to accommodate any issues that might happen in renders, but this is assuming that the app was installed from just an ".air" file that requires the AIR runtime be installed on the system to function and can be updated independently of the AIR app. It should be considered though that those are all theoretical concerns and not guaranteed to be issues. Especially if the HTML/CSS was written correctly with no markup issues. I understand one concern would be in app file size if including the AIR runtime because I have a simple app with just code assets, some Flash vector buttons, 1 font bundled, and my app is 67MB. Perhaps that is a greater discussion about AIR apps in general. Sorry for the long rant but I'm sure everyone here has at least some level of frustration that this thread is 2 years old and seemingly no progress has been made other than a decision has been made to create an ANE at some point.

Known Participant
September 22, 2016

Well I just found out that it is impossible to load Google+ pages URL's in HTMLLoader ..

TA'RI - About - Google+  works in the browser but not inside a HTMLLoader (results in a 404 error).

So let me just say I understand your rant

wigginsry
Participant
August 14, 2016

OK, I'll join the StageWebView madness discussion.

Using Windows 10 (all updated as of this post) with useNative set to true.

Agent String reported is:

"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 10.0; WOW64; Trident/7.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729)"

I've tried not using native - it's better, but not perfect (javascript errors, svg issues).

I've tried compiling using AIR 21.0 as well as the AIR 23 beta (23.0.0.230) - no luck.

I've also tried HTML Loader, but - as expected - it was no better than stagewebview nonNative.

I'm only concerned about Windows desktops (it's a kiosk application, and I have control of everything except for that it's running Windows - so if there's a way to change the default web rendering, I'm up for it (changing the default browser doesn't appear to affect StageWebView))

I'm a tad frustrated, and given that some of these issues seem to have been identified years ago - I'm not convinced I made the right choice doing this particular application in AIR (Adobe Animate CC 2015.2). Sometimes... just sometimes.. I miss my Macromedia Director days.

User Unknow
Legend
August 17, 2016

I use Google Chrome in Kiosk Mode

Known Participant
August 17, 2016

I really hope that by next release Adobe will have an updated WebKit or include an ANE for Windows with latest / greatest web kit... waiting Adobe....

March 29, 2016

I would like to see StageWebView(false) supported on Android.

useNative:Boolean (default = false) — When useNative is false, a version of WebKit embedded within AIR is used as the source of the StageWebView created.

I then need that embedded WebKit with AIR to be updated to the latest version.

Will this ever happen?

March 30, 2016

I found this today. Has anyone tried this out? It looks like it might be way better than what adobe currently offers us

http://www.myflashlabs.com/product/rich-webview-ane-adobe-air-native-extension/

Participant
April 27, 2016

Thanks. This worked for me! You saved my app with this great ANE.

Participating Frequently
February 15, 2016

I have pretty given up any hope of this happening - I am currently laying some ground work to rewrite my app with TypeScript and Electron, meanwhile it would be nice for this to happen to improve the AIR app experience for users while the new app is built.

Participating Frequently
February 11, 2016

So AIR 21 is now on labs.adobe.com and still no sign of this?

February 15, 2016

At a year and a half later from the first post from Chris on this subject matter and my development team has moved on to web tools built with HTML5 and JS combined with browser plugins to get our needs met. Honestly it speeds up the update cycle since I don't have to issue app updates that have to go through IT in order to get internal AIR apps updated.

I have always been a huge AIR and Flash supporter in my office, but now it is starting to feel like it isn't worth the effort to defend uses of Flash and AS3. I hate being a negative person on this with how much I love the development tools Adobe has built, but I am starting to understand others outlook on it when the last response from Chris was almost 6 months ago.

March 26, 2016

Don't give up. Keep demanding this issue gets fixed. Please demand an upgrade to the latest WebKit so that we can use HTML5 and JS! Adobe promised us that Actionscript and Javascript would be first class citizens in AIR. They owe it to us to fix this issue immediately.

Known Participant
December 9, 2015

Hi Chris,

We personally we don't mind any of your proposed solutions. using ANE is fine, or an entirely new embedded WebKit is fine as well...

As long as Adobe provides a stable integrated latest browser solution, we are find with any option!

If ANE is the best route, it's 100% ok by us, but we would like to be able to choose which browser to launch, as we are interested in Chrome (not IE) and obliviously in a  chromeless running mode

as always thanks,

Regards,

Sean - http://DigitalSignage.com

____________________________________________

MediaSignage.com, FREE Digital Signage for everyone!

5776-D Lindero Cyn Rd #182

Westlake Village, CA 91362

Phone: 1.877.DIG.SIGN (1-877-344-7446)

Fax: 1.818.337.0442

Live support: http://chat.digitalsignage.com

Participant
December 21, 2015

The HTML half of AIR hasn't been a priority of Adobe's since AIR... v1.5 probably. Even if Webkit is updated, you can't expect it to match something like Chrome's performance unless you also use V8, at which point you might as well use Chromium, at which point you might as well be using NW.js and not Adobe AIR (which uses Chromium + Node.js). - Link: NW.js . I switched an HTML/CSS-based app from AIR to NW.js about a year and a half ago, and holy crap was it orders of magnitude better.

If you're doing anything HTML-based, it's not Adobe's priority. The priority for AIR moved a) to Flash-based, even though Flash was dying, and b) to mobile away from desktop.

I mean, even if this is updated, look at the length of time to get a modern web engine. Do you really think AIR is going to keep up? It might be painful, but I would highly recommend abandoning AIR.

Known Participant
December 21, 2015

for us having any newer HTML5 would sufficient... we dont need super fast rendering, more needing a HTML to support all the newer JS/CSS.

every case has its own pros and cons...

December 9, 2015

Hello Chris, okay?

Any news related to this topic?

Upgrading is easy, difficult or almost impossible?

In addition, there are plans to update the Adobe Air SQLite? This is also a constant request from the community.

Thanks and hugs.

Participating Frequently
November 18, 2015

We want to use the WebView as a wrapper for CreateJS content made with Flash. Think about it... I can write a game in JavaScript, use Flash to lay out the scenes, and then wrap that content with Adobe AIR to release as an app. With a little batch scripting, I can publish an extremely portable HTML5 game in a couple of clicks, with an IPA, APK, and AIR installers all included. It's much more simple than using PhoneGap, seriously.

It's not an ideal solution when it comes to file size, but it would have a lot of upside in my eyes. Currently, it just runs too slow. Most of the content loads correctly, but the frame rate is like 10% of Chrome.

Known Participant
November 18, 2015

yes that's why we need Adobe to update to the latest rending engine.. (i.e.: WebKit)

Inspiring
November 19, 2015

Yes. I need an update as well. New websites are not loading because SVG and data uri images are not supported in the old webkit. Many pages are not viewable.

BTW There is an odd file with the AIR webkit dll. It is named Notice_WebKit.txt. It says:

Under the terms of the GNU Library General Public License, you are permitted to make changes to the Webkit library for your own use, and Adobe delivers with the installed Adobe software the object code that links with the Webkit library, as required by the GNU LGPL. You are also permitted to reverse engineer only those portions of the Adobe software that link with and utilize the Webkit library, and only to the extent necessary to debug your changes to the Webkit library. Any other reverse engineering, decompiling or use of utilities or tools to trace, probe, or reveal Adobe software and trade secrets embodied therein, is expressly prohibited. Adobe software contains valuable trade secrets and employs methods protected by patents of Adobe Software Incorporated.

I have tried using a new version of webkit.dll and the version number is the same or the app immediately closes (using AIR 3.6 not tried newer). I have spent a few days on this. New websites do not load and some are broken, even Adobe sites because of img data uri not showing.