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

[nemenv]

Using eval seems a bit hacky to me. I would be interested to see how the performance of calling eval on every frame would compare to just manipulating native DOM objects in AS.

[Aaron Beall]

I think I like the idea of using StageWebView with support for JS interoperability. At first I shuddered at the thought of losing HTMLLoader because I definitely don't like the inconsistency of JS in browser (that's one big reason I use Flash and AIR to begin with!) but for the things I want HTML rendering in an AIR app for I could live with it for the benefits of [probably] having a more modern web view faster.

However there is one thing I'd really like to be able to do, and that is layer StageWebView within the AS3 display list. My understanding is that currently you can't do that with StageWebView like you can with HTMLLoader. The reason I want this is because in some apps I use HTMLLoader as a means to display rich user supplied content that the regular TextField can't handle.

One final thought: I don't really know how AIR queries for the "system installed webkit" but it would amazing if we could actually require a certain version of webkit, giving the user a way to update their system webkit outside of updating their web browser. I'm guessing that's not possible, but I would love it, because then it would give me at least some control (if necessary) over the environment my JS will run in.

Cheers!

[johnwuapps]

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.

[nemenv]

Any updates on the status of this issue?

[kotaro_tokyo]

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.

[itlancer]

Hi Chris,

We need more interop in StageWebView like with HTMLLoader. I mean locationChanging events etc.

Feature request here: Feature#3802953 - [New Feature Requirement] StageWebView improvements

[Guest]

Going through all the comments here, it looks like most people would like to use StageWebView and have it contain features that HTMLLoader has today. I previously supported just updating the built-in webkit, but after further consideration, I could get behind StageWebView for desktop if it had the ability to get a list of browsers installed on the computer and pick which renderer it should use. So in the case of Windows computers, if the user had Firefox, Chrome, or Safari installed, be able to use one of those browsers renderers if that is possible instead of IE. The biggest thing I would like to have is HTML5/CSS3 support and events that ActionScript could respond to.

[itlancer]

Absolutely right!

[nemenv]

the biggest issue with StageWebView is that you can't put anything on top of it which makes it useless for any complex desktop apps, and not a suitable replacement for HTMLLoader

[Guest]

Hey Chris,

Thank you for reaching out to the community! Our team has been working on AIR apps for a while now. It has been frustrating to say the least, trying to integrate sophisticated HTML5 apps into our different AIR apps.

The existing solutions on mobile and desktop are not very satisfying. Mobile has gotten better because of the StageWebView, but there are still several flaws that make the platform unpredictable. On desktop it is even worse and we are facing a tough decision.

We want to integrate an HTML5 app into an already existing AIR app. The two applications will have to communicate in some form with each other. The StageWebView approach with a simple ExternalInterface would suffice, as long as we could pick from the browsers that are installed. The ANE class approach also sounds good, but only if there is a similar way of communication.

We think that keeping the component (WebView or ANE class) as lean as possible is one of the most important things. We don't want to face the same issues in the near future. There is also a need to update that underlying layer fast. Browser vendors (with some exceptions of course ) have much faster release cycles nowadays. They will keep pushing the boundaries and we need to adjust accordingly.

The HTML5/JS should take care of the DOM manipulation, event handling and communicate back to Actionscript in a simple way. There is no need for Actionscript to worry about these things. And if there is, create a simple JS layer using the interface to do the job.

Here is a list of features that are essential to us:

1. Accessing the local file system (xhr requests on the local file system):
   Worst case scenario: Using the ExternalInterface to feed files to the HTML application.
2. Configure the cache or at least manipulate cache handling
3. Much better HTML5 / CSS3 support: Video, Audio, SVG, CSS3 Animations, etc.
4. Easier and faster way to update the underlying WebKit/Chromium (relevant for ANE)

Are there any plans yet? Is it on your roadmap? Are we talking about years or months? Answers to these questions are very crucial for us. Only with those answers will we know, whether we can keep working on the AIR platform or if we have to look for alternatives and migrate our entire application.

We are looking forward to your answers.

Thanks

[Thulasiram_soft]

Title

Incorrect functionality of embed tag in html loader for adobe air development

Description

Problem Description: If we had loaded youtube.com video url in a view stack and navigate to other index of stack or away from we UI screen within the same native window video or embedded tag of flash player or any other embede object will be displayed on top of all screens layer in same position of where the object should be placed in side of html loader only.

Steps to Reproduce:
1) go to http://get.straweb.com/StraWebBrowser/StraWebBrowser.air download and install
2) load 2 tabs and in the 3 tab load video player of youtube.com which will a sample video
before completing the load of 3 tab which trying to load video from youtube.com, navigate to other tabs 1 or 2 in few second once the flash player of youtube.com video player is load it will display in the current tab or UI screen.
3) Try navigating to other tabs than youtube.com loaded tab you see the flash player is on top it stable.
4) navigate to 3 tab and try to navigate to other tab you can observe that so how it will not show that flash player and only visible in that 3 tab which is fine.
Actual Result: Embedded tag of html page displaying on top of all layers of Adobe air application native window

Expected Result: Embedded tag of html page should only displayed in side htmlloader

Thanks,

Thulasiram .S

[mpguerin]

Hi Chris, we're six months down the line from the thread you started. I wondered if you could give us an update on this?

[MisterPinC]

These are some of the features I'd like to see.

Interop between JS / AS3 is crucial.  It is no inconceivable that a developer would want to build their entire application in HTML5.  If a developer wanted to use AIR instead of PhoneGap that should be a viable option.

Full HTML5/CSS3 features - including WebGL & Video

Ability to have the HTML content display either in front or behind the display list.

Ability to render your HTML content to a texture for use in Stage3D.

Using an ANE is a good option since it allows for flexibility - especially if it is open sourced - the downside is it becomes a lot harder for people new to the platform to use.  This seems like a minor tradeoff to me. 

[itlancer]

Please consider PhoneGap integration with Adobe AIR to improve StageWebView/HTMLLoader.

Feature request here: Feature#3832476 - [New_Feature_Requirement] Adobe AIR PhoneGap integration

[goldysilva]

Hi Chris, any progress on this? Please let the community know where we are with this important issue.

[chris.campbell]

Nothing to report yet.  I know this is an important issue so I will keep on this.

[goldysilva]

Thank you Chris ... highly appreciated

[Guest]

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. http://www.trainingintambaram.in/web-designing-training-in-chennai.html | http://www.trainingintambaram.in/php-training-in-chennai.html

[Born2code]

Hi Chris,

Any update on when will Adobe update AIR HTML component to be latest HTML5?

We really need this update!

Regards,

Sean - http://DigitalSignage.com

[Born2code]

It's June 2016... anything new as far as HTML5 for AIR Desktop?

Adobe, pleeeeeeeease.....

[tufik12]

Is better forget Adobe Air, you know that Adobe is not developing this technology anymore, only maintenance with a little team from India.

[gperry91]

I completely disagree. Have you not been following the recent updates? The AIR team seems more active now than they have been in years.

[Born2code]

I agree, AIR ROCKS!!! and the team seems to be pushing faster and faster...

[tufik12]

I like AS3/AIR technologies and wish a best future to it, but the reality is completely different. If Adobe is working hard in AS3/AIR should have a strong coverage to the major functionalities in Mac/Window/Android/Windows Mobile/IOS like others active technologies (example: xamarin), present their future plans in Adobe Max like time back and improve in code (ES7), etc.

The majority great changes arrives of third company like ANES, not from Adobe team. Many time ago Adobe stop to speak about it, and turn slowly the apps like (Adobe Animate) to HTML5. And to end.... remember the date of this post: 27-ago-2014, very old.

"i know, i know, Adobe go fast"...

One thing is what we want to happen and another thing is the reality of what is happening.

[gperry91]

tufik12 - Chris Campbell posted this only yesterday.

"The current plan is for our engineering team to put together an ANE based on the Chromium embedded framework (CEF) and include a tutorial that helps developers understand how to implement this solution in their applications.  We'll start with that and gather feedback to see if it helps.  I'm hoping we can get to this later this summer, schedule permitting."

Happy now?