Why is StageWebView using the app-breaking Internet Explorer rendering engine from AIR 3.6 onwards?

[OMA2k]

I'm having a hard time getting an old app working in Windows with the newer versions of Adobe AIR (3.6+) because for some reason Adobe has ditched the WebKit engine which was used in StageWebView in AIR 3.5 and older versions, and now it uses the Internet Explorer (Trident) engine instead. Yuck!

The worst thing is that the version of the engine used depends on what version of IE the user has installed in the system, so we have yet again the age-old problem (for web developers) of dealing with old shabby versions of IE, which we didn't have before in AIR, because StageWebView used to leverage a built-in WebKit engine in up to AIR 3.5.

Why did you have to change the engine from the really reliable WebKit engine to the buggy Internet Explorer one?

This only results in problems of all kinds:

- This breaks existing AIR applications which worked fine up to now.

- Developers have to spend extra time for users with old computers and out of date browsers, such as IE6, IE7, IE8 and IE9, which produces all kind of extra headaches (old versions of IE don't support a lot of JavaScript methods such as addEventListener, atob, btoa, the JSON object, etc, so you have to add extra code to do those things, not to mention having lots of CSS layout problems and other bugs). There are lots of users who never upgrade their IE, because of ignorance or maybe just because they're using another third party browser and don't care to upgrade a browser they don't use, even if they're prompted by Windows Update to upgrade their IE. So this is an important issue.

- Also, even with IE10 the engine fails currently to properly display CSS and run JavaScript under some circunstances (inside StageWebView)

- Future IE updates (IE11?) can break existing applications even if they work now (this happened in the past with Microsoft HTA applications, which relied on old versions of IE installed in the system and broke with newer versions)

- Now the user can right-click the StageWebView and make a contextual menu appear in the screen, with confusing and undesirable options (such as "view source code"). With AIR 3.5 and older, no contextual menu appeared at all, which is much better for a desktop application (in a browser people expect a contextual menu to appear when right clicking, but not in a desktop application where the user doesn't have to even know if what is on display is a web page or not).

And now, the advantages of using Internet Explorer as the browsing engine:

- ...

Well, I can't think of ANY! Could anyone please tell me, what was the rationale behind ditching the WebKit engine?

Can any Adobe AIR developer at least explain the reasons, please?

Thank you.

[OMA2k]

No word from anyone from Adobe's staff?

[johntmcii-3]

Thank you, OMA2k, for this post.

Word from Adobe?  Anyone.  Throw us a bone.  We're obedient, for the most part.

[chris.campbell]

Hi guys,

I talked with the team about this on Friday last week, I'm sorry we haven't gotten back to you sooner.

Our initial recommendation would be to recompile your application to use HTMLLoader.  While StageWebView uses the OS web rendering engine, the HTML control still uses the built in webkit.  However, I realize that you might not have access to the original code, be unable to distribute an update, etc.

Our intent with this change was to have StageWebView use a light weight interface to the OS rendering engine.  We wanted you to have the best performance possible with the most up to date security.  There were other issues we were also trying to tackle, such as decarbonizing on Mac that also influenced our decision.

All that said, we get where you are coming from, especially with Windows.  I don't think it would be unreasonable to have an api that would allow you to choose if you want StageWebView to use the internal webkit or the OS version.  Maybe the default would be to use the internal webkit so that older apps aren't impacted.  This would be a great bug report / feature request.  Getting comments and votes from other developers would also allow us insight into who is using this feature and has been effected by our changes.

If you'd like to enter a bug, please let me know the bug number and I'll take it to the team for review.

Thanks,

Chris

[johntmcii-3]

Hi Chris,

Thank you for detailed response.  This helps me.

John

[OMA2k]

Thanks for your answer, Chris. Now at least I have an idea of why this was changed.

Your suggestion of using HTMLLoader doesn't work for me because I need the app to work for mobile as well with the same codebase. That's why I'm using StageWebView (in fact I'm using it through the StageWebViewBridge wrapper library by Pedro Casaubon, so changing to HTMLLoader just for the desktop version is even less of an option).

But I find interesting your idea of having a property to choose the engine. That would be the real solution!

So I've added it here:

https://bugbase.adobe.com/index.cfm?event=bug&id=3584066

Everyone reading this, please add your vote there so this feature gets implemented

Thank you!

[Frédéric C.]

Hi OMA2k,

Thank you for this suggestion. Actually I tried to use the stagewebviewbridge class with AIR 3.7, but the DEVICE_READY event is never fired on Windows. Is it due to the recent use of IE as web engine? It seems to work on iOS though, but is a nightmare to test if the initialization doesn't even work on desktop.

Thanks!

[OMA2k]

Frédéric C. escribió:

Actually I tried to use the stagewebviewbridge class with AIR 3.7, but the DEVICE_READY event is never fired on Windows. Is it due to the recent use of IE as web engine? It seems to work on iOS though, but is a nightmare to test if the initialization doesn't even work on desktop.

Yes, it's because of that. Only happens in Windows because it's the only OS with Internet Explorer. The rest of OSes have WebKit as their native engine.

You can temporarily fix the problem by using AIR 3.5 SDK (you can find it here), which uses an embedded WebKit engine instead of the native IE engine, but I hope the Adobe team implements an option to use the embedded WebKit in future versions of AIR as well. That could solve a lot of unwelcome problems derived from IE.

[Frédéric C.]

Ha thank you! I struggled a bit with this class, I was wondering what I was doing wrong!

Indeed, having the possibility to use the Webkit engine would be great!

[OMA2k]

Glad I could be of help. If you think having that webkit switch is a good idea, please vote for it here:

https://bugbase.adobe.com/index.cfm?event=bug&id=3584066

Thanks!

[OMA2k]

An answer have been posted in that bug report:

"Our engineering team is investigating this.

This bug means the issue can be promised to be fixed in the near future release, please continue vote the bug before it final get resolved"

So, please, keep on voting 😉

https://bugbase.adobe.com/index.cfm?event=bug&id=3584066

[Frédéric C.]

Awesome! Keep up the great work Adobe team!

[Frédéric C.]

Thank you so much Adobe for listening to your users, and bringing back the Webkit engine into the latest AIR 3.9 beta!  You rock!

[chris.campbell]

Thanks Frederic!  Please let us know if you run into any issues.

[OMA2k]

Thanks a lot for implementing my BugBase suggestion! It's of great help for apps running in Windows which use StageWebViewBridge. The Internet Explorer engine is a nightmare to deal with, specially if the user has an old version. Now it's not a problem anymore.

Also, thanks Chris for suggesting this change in the first place