Copy link to clipboard
Copied
Hehuan Liu stated in:
https://bugbase.adobe.com/index.cfm?event=bug&id=3630656
That the Adobe Air team were planning on updating the Air Webkit object.
Could you provide an update?
Is there a way for us to track the progress of this issue?
Kind Regards,
Adrian Smith
Copy link to clipboard
Copied
I'm interested in an update on this too.
Thanks,
Marc Guerin
Copy link to clipboard
Copied
Me too.
Copy link to clipboard
Copied
Would be nice to get an update on this.
If you run anything in the html component that takes even a short time to complete then it becomes unresponsive.
The onclick event handler still fires every time for the flex component itself but any javascript event handlers fail if they happend to coinside with any work javascript is doing in webkit, it seems to be ok if flex is working, but not the javascript in the html.
I wonder - is this a shartfall of the webkit version or is it do do with the single threaded nature of flex.
If you bash the hell out of a webkit version this old with javascript loops, does it become unresponsive to jquery event hadlers in a way that an up to date version doesn't?
Copy link to clipboard
Copied
ABOBE – WHY NO UPDATE?
Copy link to clipboard
Copied
ABOBE – 2 WEEKS NOW - AGAIN I ASK WHY NO UPDATE?
Copy link to clipboard
Copied
I’m on some of the Adobe betas, and sometimes Adobe just stay quiet until they have news for the world. For example, the recent announcement about supporting x86 with AIR for Mobile was news even to us on the betas.
So, you may just have to be patient.
Copy link to clipboard
Copied
Really appreciate the comment Colin.
It is pretty poor that somebody in the Adobe Air dev team won't write a few words though.
Nobody can say they're too busy for that.
Copy link to clipboard
Copied
Hi guys,
I think Hehuan might have confused this with another issue. The team is aware of this request from the community but we don't have plans at this time to make any updates to the internal version of Webkit. That said, I'll make sure to bring this up to the team again (it's in the top 20 on the uplist.) It is however, not a trivial change.
Part of the problem we've had was understanding how often this feature was used by customers. We introduced StageWebView, which uses the html rendering engine native to the OS, which we had hoped would at least reduce this issue for some customers. We have since received feedback that this won't be sufficient for some that need more sophisticated functionality. Getting feedback on the uplist helps us understand the impact and prioritize properly.
Thanks,
Chris
Copy link to clipboard
Copied
Wow! It's worrying to know that Adobe actually employ people who cannot read! Let alone those who give false hope to those that depend on a feature enhancement like this one! Once again, Adobe have done it again with their announcement balls up (referring back to the time when you announced the donation of Flex for the first time which was worded in such a way that it sounded like Flex was no more)!
It would helpful if you could share a roadmap so we know when to expect such a feature, just like you did with the Flex SDK back in the day.
Copy link to clipboard
Copied
@RandomReado - Mistakes happen but I'll ask Hehuan to take a look at the comment and remove it if possible. I apologize that it was incorrect information.
Our roadmap can be found here: http://www.adobe.com/devnet/flashplatform/whitepapers/roadmap.html
@nemenv - StageWebView uses th system's browser (IE on windows, Webkit on Mac.) You are correct that this won't help users that require AS to JS communication that the html/htmlloader control gives you with AIR's built in Webkit.
Copy link to clipboard
Copied
On the Flash Platform reference it states:
"The features available and rendering appearance are the same as those of the HTMLLoader class"
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/media/StageWebView.html
I just did a test and both HTMLLoader and StageWebView have the same userAgent on Windows 8.1:
"Mozilla/5.0 (Windows; U; en-GB) AppleWebKit/533.19.4 (KHTML, like Gecko) AdobeAIR/13.0"
Copy link to clipboard
Copied
Try with new StageWebView(true) instead of plain StageWebView().
Copy link to clipboard
Copied
That worked - however no JS-AS comms and it not being part of the display list is big problem.
Copy link to clipboard
Copied
I tried using StageWebView(true) too, however the UI still renders radio buttons and other HTML controls the same way as the traditional HTML component does. Also the UserAgent reads:
"Mozilla/5.0 (Windows; U; en-US) AppleWebKit/533.19.4 (KHTML, like Gecko) AdobeAIR/13.0"
If it uses the default system engine to display the web page, why does it still reference WebKit?
Google Street View accessed via maps.google.co.uk works in HTML or StageWebView but I'm guessing this is because it's a Flash Player viewer. The HTML5 viewer (Street View API) still does not work, even with StageWebView(true).
Copy link to clipboard
Copied
I've just tested it out of curiosity, and I get the same user agent as my system browser (IE 11), and the HTML 5 Street View works as expected.
Copy link to clipboard
Copied
That's interesting, if I use Adobe Flex 4.6 which uses AIR 3.1, Flash Builder throws an error claiming StageWebView() does not accept any arguments, even though the documentation states the useNative argument was available in AIR 2.5.
If I use Flex 4.6 + AIR 4.0 SDK, I don't get the error when I using useNative=true, but the StageWebView says it has a UserAgent that references WebKit.
I get the same issue if I use Flex 4.6 + AIR 13 SDK.
However, using Flex 4.12, I get a UserAgent of IE11 and the Street View HTML5 viewer works fine.
@Neverbirth, what Flex SDK did you use in your testing?
Copy link to clipboard
Copied
The documentation says AIR 2.5+, because StageWebView, and thefore the constructor, was added in AIR 2.5, but useNative was added in AIR 3.9 I think.
The Flex SDK does not matter, as this is a feature from AIR, I tested it using plain AIR 13 with ASC 2, but tried it with Flex 4.11 and 4.12 as well. The problem is surely caused because the useNative argument depends on the SWF version you use to compile your project. I case you need to use Flex 4.6 you can either use a -swf-version=22 compiler argument, or edit your flex_sdk_path\frameworks\air-config.xml file, and modify the default <swf-version>14</swf-version> and <target-player>11.1</target-player> values to <swf-version>22</swf-version> and <target-player>11.9</target-player>.
Copy link to clipboard
Copied
That makes sense! Also the swf-version=24 works for me. Thanks very much!
Copy link to clipboard
Copied
You can get JS-AS communication, there are articles online, but it can get painful and not always possible unless you make a lot of work. When the content is static you could also get a capture from StageWebView and use it as a display object, but of course, it's not always going to suffice.
Making StageWebView part of the display list would be great, but it's not going to happen... as it just uses the available browser control, you'd need some serious hacking, that I don't know if it would be available on all supported platforms, and since HtmlLoader can't either be used on all platforms, it would not make sense to have two not multi platform browser implementations. Of course, all of this is aside from the original subject here, and I'm in favor of updating the internal WebKit implementation, and StageWebView could get some improvements, like DOM inspection-manipulation, JS communication, and the like that would work on every platform.
Copy link to clipboard
Copied
i work on an internal tool at my job that uses a HTMLLoader as the work area. It is tightly integrated with the rest of the app and would not be possible with the StageWebView. Things like selection bounding boxes and guides are drawn over the HTMLLoader object:
Copy link to clipboard
Copied
I am building an AIR for desktop application. I am also using Stage3D which requires render mode='direct'.
I need to be able to load in external html, in my case a some standalone html.
At first I thought using the new StageWebView class with native browser option would be the ideal solution. However I discovered that my html content was loading but was 'invisible' only in Mac OS X. After a lot of googling I surmised the problem was 'render mode=direct'.
Copy link to clipboard
Copied
Correct me if I am wrong but doesn't StageWebView use the HTMLLoader on the desktop? So introducing StageWebview would not have helped anyone who relies on the HTMLoader for desktop apps. Even on mobile StageWebView is pretty useless since there is no AS to JS communication unless you do some serious hacking to get it to work.
Copy link to clipboard
Copied
Another vote for a modern WebKit.
We have a web app that uploads video files directly to YouTube. To do this it uses HTML5 features: XHR2, FormData, FileList, and Blob. When this app is loaded via AIR it doesn't work because those features aren't available. The AIR environment isn't available either since it is loaded via web request. So the problem we have is how to develop modern interfaces and interactions using an old browser environment. We don't want to have two code bases, one for customers using the web site and another for customers using the AIR app.
Copy link to clipboard
Copied
If you haven't seen this already, we'd love to get your feedback and answers here:
How do you use AIR's WebKit/htmlloader?
Thanks,
Chris