Highlighted

How do you use AIR's WebKit/htmlloader?

Adobe Employee ,
Jun 10, 2014

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

TOPICS
Development

Views

31.1K

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more

How do you use AIR's WebKit/htmlloader?

Adobe Employee ,
Jun 10, 2014

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

TOPICS
Development

Views

31.1K

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Jun 10, 2014 20
155 Replies 155
Community Beginner ,
Jun 11, 2014

Copy link to clipboard

Copied

Hi Chris,

I am currently working on a project which led me to upvote this issue. I am loading in a URL using HTMLLoader (the mx:HTML control) and after the HTML is loaded I can manipulate the DOM. So I can hide specific parts of the loaded webpage. This is working fine only I am facing an outdated version of webkit so new HTML5 functionality does not work well.

If you can expose the DOM via the ANE and allow functions to alter it this would be fine by me.

What I think is essential:

- locationChanging event (with support for #)

- locationChange event (with support for #)

- complete event (html page loaded)

- access to DOM to show/hide specific elements and/or rewrite/replace the source code of the webpage to see immediate effects (this we use for a WYSIWYG editor to preview changes), like domWindow.document.getElementById, getElementsByTagName, getElementsByClassName

and to be able to do things like:

foundElement = browserHTML.domWindow.document.getElementById("content");

  if(foundElement) foundElement.style.width = (this.width-36) + "px"; //take scrollbar into account

- location property for the current page (with support for #)

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Jun 11, 2014 0
Participant ,
Jun 11, 2014

Copy link to clipboard

Copied

My primary use case for a web view in AIR would be to open "accounts / settings / management" pages that are already available via the web to my users.  In this case, layering on top is fine, and ExternalInterface is very useful.  A recent version of webkit (to guarantee proper page rendering) is the biggest need.

So I'd be happy with an up-to-date and embedded (to guarantee cross-platform consistency) webkit providing StageWebView with an ExternalInterface bridge.

If I recall, HTMLLoader as a DisplayList object could be layered in the displaylist and rendered to Bitmap, which is cool, but I'm guessing is part of what made it complex.  But if HTMLLoader is staying as-is, then it could still be used for these use cases.

Aso if I recall, with StageWebView you can hack interop with location change events - ugly, but it provides basic communication capabilities.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Jun 11, 2014 0
New Here ,
Jun 11, 2014

Copy link to clipboard

Copied

StageWebView exposing an ExternalInterface would be perfect for a lot of things.

Exposing DOM elements would be even better (everything Frederic Cox mentioned above looks very interesting.)

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Jun 11, 2014 0
Engaged ,
Jun 11, 2014

Copy link to clipboard

Copied

Pretty much what FredericCox said. It gets harder and harder loading html5 content with webkit being outdated and AIR apps that used to work fine when developed and first released keep breaking after a while when the (3rd party) loaded content is updated.

I was actually hoping to see webkit be replaced by something like chromium.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Jun 11, 2014 0
New Here ,
Jun 11, 2014

Copy link to clipboard

Copied

What would be good would be to update the HTML loader but also to introduce a standalone library that could load modern web code and be manipulated within the runtime. External interface was nice originally because of the type cohesion between JavaScript and actionscript. So passing objects worked seamlessly etc. My understanding is that it should even be possible to cross compile something like chromium using flascc and actually include it directly in a project as an ABC library. The interface that's written in swig would probably determine the available capabilities. In theory though it would be a game changer to be able to create a browser object that uses latest sources and manipulate it like any other object in actionscript. This would also allow you to use HTML tools like edge along side actionscript in a given application. That is obviously a business value not to mention a way to combine technologies which was the original intention of Adobe's contribution of avm2 for tamarin.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Jun 11, 2014 0