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
Hi Chris,
Happy to answer any questions/clarifications you need. It's been two months since you last responded to this thread. Could we please be told what's happening here? It would be nice to be told if this is coming and when. What are the roadblocks which prevent this being implemented?
Thanks,
Marc
Copy link to clipboard
Copied
+1
Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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)
Copy link to clipboard
Copied
Agree with FredericCox
Controling loaded DOM is needed for all my projects. I'm working on Adobe Air desktop all the time with education projects, while controlling cache, user agents, loaded HTML DOM (get & modify html contents) is minimum requirement. Without such feature, I have no reason to use Adobe Air.
Adobe Air is the best platform to build education applications.
Copy link to clipboard
Copied
Hi Chris, any news on this yet? I keep running into issues with content using SVG, I tried creating a canvas fallback but the HTMLLoader doesn't have the Path2D object which is required to draw SVG paths. Tools like RaphaelJS also fail because Raphael's fallback is to use VML which is IE only and so it doesn't work. Content using the latest JS version of GSAP also has the tendency to fail because of some SVG/fallback related code in the library, even when SVG is not actually being used.
Copy link to clipboard
Copied
googlemap on air desktop and mobile
Copy link to clipboard
Copied
WKWebView support would be a huge improvement, we really need this feature !
Copy link to clipboard
Copied
Hey Chris,
I acknowledge that working with webviews on Windows is a major challenge. Even the HTML5 platforms (Apache Cordova API Documentation) have a hard time supporting webviews on Windows (since there is no native equivalent yet - maybe on Edge, but it's not ready). Expecting Adobe to compile Webkit at each major release for Windows and Mac is not realistic (side note: devs shouldn't complain, as other platforms face the same challenges).
Some ideas:
1. Is there a way to simply use Chromium? I understand all the security concerns, so why not 'outsource' this and expect Chromium's security model to take over that part. You can call a chrome App silently from the command-line. So we could have a Chrome App which is an interface to the Chromium browser and AIR app communicates with this Chrome app to control (one or more) chrome.webview instance(s).
2. Use Internet Explorer with OLE automation - Edge may discontinue that, but not sure as I am expecting a lot of business users are using this feature. We need to investigate if we can hide the UI bar, but not an issue, as it is platform specific and users would understand.
Some ideas to speed things up.
Copy link to clipboard
Copied
Or ...
(3) Build an ANE around Embedded Chromium Framwork CEF3 Builds -- which is hosted - ironically - by Adobe [i vote for this]
Copy link to clipboard
Copied
I'm really leaning towards (3) too, with the added part that this should be an open source ANE. I've hoped to have started further investigation into this by now but we've had other priorities bump this. It's not forgotten though, and I'm hoping we might see it in a v21 time frame.
Copy link to clipboard
Copied
I really need some new javascript skills available to me. I'm looking for "localStorage". Many projects use it. I don't know what node.js is but it's really hot. Being able to include node.js projects with the click of a button would be really powerful.
Would an ANE be powerful enough to accomplish the entire wish list asked by the community?
Copy link to clipboard
Copied
Hey jf15590689‌,
Not sure I understand your question.
1. Node.js is a server framework built on top of a JS engine. Meant for desktop / servers.
2. If you need localStorage, checkout SharedObjects in AS3.
3. Finally, ANE's are for native-based needs that are best served (or sometimes 'only' served) with source code for the target platform.
Copy link to clipboard
Copied
I know about SharedObjects. My problem is I just want to grab js code and load/update it into my project without modification. Most new js projects use localStorage and it seems like every new js library is packed up as a node.js app. I have to use browserify to use the code in StageWebView.
Copy link to clipboard
Copied
Chris, it has been 2 months now since your last reply. Is there any new information? By "v21" did you mean AIR 21 and does that mean in the next 3 to 6 months since API 20 is currently in beta?
Copy link to clipboard
Copied
An open source ANE should be done ASAP. An amazing native component should be the long term goal. A new webkit should be included in the next version of the SDK.
Copy link to clipboard
Copied
If Adobe was to go with the ANE route does that mean you won't be able to add UI in the display list above the ANE's web view? Correct me if I'm wrong but most ANE solutions I have seen just plonk a web view (or some other UI element) above display list which is a pretty terrible solution and presents the same problem as the StageWebView.
Webkit was integrated in AIR 1 with equivalent Webkit to Safari 2 and was upgraded at various releases until AIR 3 which had the equivalent Webkit to Safari 5 (see: Adobe Flash Platform * About the HTML environment). Why is it now deemed too hard?
Copy link to clipboard
Copied
@nemenv,
The challenge faced is that Webkit is changing all the time and needs to be recompiled. That being said, and on further thinking, if we could just get a recent compiled version, most of us would be satisfied (Chris?) -- webkit has not changed a lot recently, but has changed quite a bit since it was compiled into AIR. The recent releases of Safari seem to be integration with Apple's platform, few bug fixes.
Now to answer your question, whether it's an ANE or not, you would get an object that you would have to define its viewport (just like StageWebView now). In all cases, it's a native process (for iOS / Android, the built-in browser, for other platforms, a WebKit process.
Copy link to clipboard
Copied
I want to throw in this feature request also:
Modify data requested by the StageWebView before the DOM or anything else sees it.
Copy link to clipboard
Copied
StageWebView(true) is broken on Windows 10. I request a complete webkit upgrade ASAP. The webkit included in AIR is out dated and now broken. This has become a must fix issue. An updated webkit from 2015 would be amazing fix. I'm missing so much JavaScript.
Copy link to clipboard
Copied
So,
It seems we all agree with a need to have a replacement for StageWebView on Windows. If we started a crowdfunding campaign, how many would be interested in chipping in? I am getting a quote shortly.
Pls like this post so I can estimate the interest. It would be then released publicly in Github and we could work out update schedules based on WebKit bug releases.
Copy link to clipboard
Copied
According to the AS3 documentation, there is no point in using StageWebView in a desktop application as it is the same thing as using the HTMLLoader class but without the benefits of the HTMLLoader object.
"On devices in the mobile and extended mobile profiles, the StageWebView class uses the system web control provided by the device operating system. Thus, the available features and rendering appearance may vary from device to device.
On desktop computers (in the desktop and extended desktop profiles), the StageWebView class uses the system web control provided by the Flash Player plugin. The features available and rendering appearance are the same as those of the HTMLLoader class (without the close integration and script bridging between ActionScript and JavaScript provided by an HTMLLoader instance). Since the HTMLLoader class uses the internal AIR WebKit engine, concurrent use of StageWebView and HTMLLoader instances is strongly discouraged as it has undefined behavior and can possibly terminate the application."
Im not sure why it has the "useNative" parameter in the constructor if mobile will always use the system web renderer and desktop will always use the HTMLLoader engine. I can only imagine it means the documentation is incorrect in some way or hasnt been updated to account the latest API changes.
Copy link to clipboard
Copied
I'm using WebKit/StageWebView to have JavaScript as an equal language in Adobe AIR. It's not very equal with the outdated webkit that's included.
Copy link to clipboard
Copied
While Adobe does not move in relation to this, we will seek a third-party solution, perhaps to be faster, visit the website below and vote:
Lack of support to HTML5 for Windows in AIR applications have been a torment.