Webkit Update Progress Report

I'm interested in an update on this too.

Thanks,

Marc Guerin

Me too.

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?

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.

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

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.

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.

@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.

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/StageWebVie w.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"

Try with new StageWebView(true) instead of plain StageWebView().

That worked - however no JS-AS comms and it not being part of the display list is big problem.

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).

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.

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.

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?

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>.

That makes sense! Also the swf-version=24 works for me. Thanks very much!

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:

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'.

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.

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