Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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...
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
Hi Chris, any progress on this? Please let the community know where we are with this important issue.
regards,
Sean.
Copy link to clipboard
Copied
PLEASE PLEASE with sugar on top give us an update to this. Still can't believe this discussion started almost 2 and half years ago.
Copy link to clipboard
Copied
any news at all will be GREATLY appreciated
regards
Sean
Copy link to clipboard
Copied
Yes an update is really needed here. This is a critical part of AIR and the discussion has been ongoing for over 2,5 years. This is getting ridiculous now. Please come up with a timeframe and an update on how the team is going to tackle this issue.
Copy link to clipboard
Copied
an update on how the team is going to tackle this issue.
The way they're tackling this is by not doing a damn thing, just like they did the past few years.
I no longer have a single AIR app that still works because of the outdated webkit engine. It's a shame really. Adobe killed off another great tech.
Copy link to clipboard
Copied
Yep, we also have to shift from Air to another Platform if this Webkit / HTML5 issue on Desktop is not sorted out.
We actually just didn´t do that cause Chris announced a solution for this "probably late this summer", now we have winter...
At least an update on what is going on would be nice.
Thank you.
Copy link to clipboard
Copied
Chris, could you give us an update on what is going on? Will the ANE make it into Air24? Air25? We at least need a timeframe to continue our development process. Thx.
Copy link to clipboard
Copied
yes please Chris,
Thank you,
Sean.
Copy link to clipboard
Copied
Hey born2code, you should write your post as a reply to chris.campbell, not to my post 😉
Copy link to clipboard
Copied
ha yes, fixing...
Copy link to clipboard
Copied
Hi Chris,
can we please get an update?
regards,
Sean.
Copy link to clipboard
Copied
I'll add our voice to this thread. We're coming up to a decision point on whether to stick with an existing investment in our AIR based architecture.
Up-to-date Webkit / HTML5 support for Desktop is the single critical factor.
I'm not sure which is more disturbing: the lack of support, or the lack of communication. Both are terrible.
A hail mary: Does anyone on this forum have firsthand experience with ANE's like NativeWebView ?
thanks!
Copy link to clipboard
Copied
I have used Distriqt NativeWebView many times and it work's wonderful. I think I also remember Distriqt saying they were getting a lot of request to make that ANE also work for the Desktop... which I believe they said they were planning on doing. So that's personally what I'm holding out.
Copy link to clipboard
Copied
That's a $50 "solution" that only works on iOs and Android. Even if (and apparently that's a big "if") they bring it to the desktop, it still won't let one do multi window applications as StageWebView only works on the main window stage.
Copy link to clipboard
Copied
we would be happy to pay much more, even for a single window would be ok, as long as it will run the latest HTML5 engine and work on both iOS and Windows...
Copy link to clipboard
Copied
I would pay 15.000 Euro to the guy implementing an AIR Desktop ANE which gives access to a better browsing experience...
Copy link to clipboard
Copied
Without wishing to spam. And for anyone subscribed to this thread.
I've created an ANE which allows you to embed a more modern webView in AIR.
It uses Chromium Embedded Framework for Windows and WKWebview for OSX
https://github.com/tuarua/WebViewANE
It won't solve everyone's issues. Project will be updated regularly
Copy link to clipboard
Copied
we should seriously collect money and pay you for your efforts...
TX MAN!!!
Copy link to clipboard
Copied
why not integrate a full web engine like blink, gecko or webkit into air and update it at every air update and make a full JS <-> bridge?
or maybe an ANE?