Using loadURL() to navigate to anchors in an HTML document fires a different sequence of events on iOS and Android

The platform API used to implement StageWebView requires a different sequence of events to fire when using loadURL() to navigate to anchors inside an HTML page. Specifically:

  • When the document is initially loaded, LocationChangeEvent.LOCATION_CHANGE and Event.COMPLETE is fired on all platforms 
  • When loading the same page but with a different anchor:

    • On Android, Event.COMPLETE is fired

    • On iOS and desktop, no event is fired

  • No LocationChangeEvent is fired after the initial load of the page

StageWebView is an asynchronous component

StageWebView uses the underlying native component to display HTML content. As such, the load and stop operations are asynchronous.

HTTP authentication dialog is not implemented on mobile (iOS/Android)

Currently no default UI is implemented on mobile for HTTP authentication. On desktop HTTP authentication uses the default OS dialog for authentication. Event though the authentication dialog is disabled, the developer can create their own UI and use the URLRequest API to do basic or digest authentication.

Content loaded via loadString() cannot access local image files

Due to a native API limitation and security restrictions, HTML content loaded using the loadString() method cannot access local contents via the file:// URL scheme.

When dealing with server-side redirection, a different sequence of events is fired on iOS/Android/desktop

When the user tries to load a page that does server-side redirection (via the HTTP Location header), a mix of LocationChangeEvent.LOCATION_CHANGING, LocationChangeEvent.LOCATION_CHANGE, and Event.COMPLETE is fired. However, the number and sequence of events fired is different between platforms. More specifically:

  • On Android
    • For every intermediary redirect (including the first page in the redirection chain), only LocationChangeEvent.LOCATION_CHANGING is fired
    • For the final page, LocationChangeEvent.LOCATION_CHANGING, LocationChangeEvent.LOCATION_CHANGE, and Event.COMPLETE are fired, in this order
  • On iOS
    • On the first page in the redirection chain, only LocationChangeEvent.LOCATION_CHANGE is fired
    • For each intermediary redirect, both LocationChangeEvent.LOCATION_CHANGING, and LocationChangeEvent.LOCATION_CHANGE events are fired
    • For the final page, LocationChangeEvent.LOCATION_CHANGING, LocationChangeEvent.LOCATION_CHANGE, and Event.COMPLETE are fired, in this order
  • On desktop
    • On the first page in the redirection chain, both LocationChangeEvent.LOCATION_CHANGING, and LocationChangeEvent.LOCATION_CHANGE are fired
    • For every intermediary redirect, only LocationChangeEvent.LOCATION_CHANGING is fired
    • For the final page, LocationChangeEvent.LOCATION_CHANGING, LocationChangeEvent.LOCATION_CHANGE, and Event.COMPLETE are fired, in this order

Errors in iframe’s are treated differently on desktop and mobile

When loading a page that contains an iframe that results in a load error, this error is treated differently across platforms. More specifically, on Android an ErrorEvent is thrown, while on desktop and iOS no ErrorEvent is thrown.

User input is not prevented on Android and iOS when using StageWebView and FULL_SCREEN mode

On the desktop, setting the stage’s displayState property to FULL_SCREEN prevents the user from inputting text except for a few keys. These keys include Esc, arrow keys, Space, Enter, and so on. This limitation is true on Android and iOS too, with the notable exception of StageWebView. For content loaded in StageWebView, users can still input text inside text controls regardless of the usage of the FULL_SCREEN mode.

Location property differences when using loadString() to load content in StageWebView

After loading content in a StageWebView, the location property of the StageWebView reflects the location from which the content was loaded. However, when loading content via loadString() the location is platform-dependent, as follows:

  • On Android, the location is the string that was loaded, Base64 encoded, and expressed like a data: URI. (For example:  data:MIME_TYPE; base64,BASE64_STRING. Where MIME_TYPE is the value that was passed for the mimeType parameter to the loadString() method and BASE64_STRING is the Base64 encoding of the string that was loaded.)
  • On iOS, the location is the string that was loaded.
  • On desktop, the location is about:blank

Location property differences when using loadURL() to load content in StageWebView from locations that contain special characters

When you load URLs that contain special characters, the actual address passed to loadURL() can be different from the address returned by the location property after Event.COMPLETE is fired. There are three distinct cases:

  • Internationalized Domain Names (IDN) – if the hostname part of the URL contains Unicode UTF-8 sequences, such as http://παράδειγμα.δοκιμή/, then the location property returns the URL as punycode encoded (http://xn--hxajbheg2az3al.xn--jxalpdlp/ for the example URL). See http://en.wikipedia.org/wiki/Punycode for details.
  • Query string containing UTF-8 characters – if the query string part of the URL contains Unicode UTF-8 sequences, the value of the location is platform-dependent:
    • On iOS the query string part of the URL is percent encoded.
    • On Android and desktop no conversion is made and the query string is returned unchanged
  • Percent encoding of special characters – some characters are not safe for using inside a URL, and as a result get percent encoded. These unsafe characters are:
    • control characters (0x00 to 0x1F),
    • extended ASCII characters (0x7F to 0xFF),
    • Space (0x20),
    • smaller than (0x3C)
    • greater than (0x3E)
    • Brackets (0x5B, 0x5D)
    • Curly brackets (0x7B, 0x7D)
    • Quotation mark (0x22)
    • Backslash (0x5C)
    • back tick (0x60)
    • caret (0x5E)
    • pipe (0x7C). For these unsafe characters, the following rules apply:
  • For URLs containing unsafe characters:
    • Unsafe characters in the hostname part of the URL are left unchanged (and most probably trigger a load error)
    • Unsafe characters in the query string part of the URL are percent encoded. Also, if the query string contains the percent character (0x25) and it is not used as part of a percent-encoded character, it too gets percent encoded (as %25).
  • For URLs containing percent-encoded characters in the hostname part of the URL:
    • If the percent-encoded characters decode to safe characters (characters not in the above list and that are not Unicode UTF-8), the URL is decoded and properly loaded. (For example, http://www.t%2Dshirts.com/ since the %2D decodes to a dash that is a valid character in URLs.)
    • If the percent-encoded characters decode to unsafe characters or to Unicode UTF-8 sequences, the page isn't loaded. It decodes to either an IDN or a URL with invalid characters in the domain name. (For example http://www.%CE%B4%CF%80%CE%B8.gr/ isn't loaded, although the decoded URL http://www.δπθ.gr/  loads fine – after conversion to punycode).
  • URLs containing percent-encoded characters in the query string part of the URL are used undecoded.

Cookies are handled differently across mobile and desktop platforms

On the desktop, StageWebView uses the same network stack as the rest of the runtime. Cookie operations are persistent across StageWebView, HTMLLoader, URLLoader, and URLStream. On mobile platforms however, StageWebView uses a native component that can bypass the network stack used by the rest of the AIR APIs. As a result, cookie operations and persistence are different on mobile platforms. The table below summarizes these differences. These behaviors apply to persistent cookies (cookies that are not deleted when the browser or applications is closed). Temporary (or session) cookies are not shared with the system browser or between applications.

 

Desktop

Android

iOS

StageWebView shares cookies with system browser

Yes (with IE on Windows and Safari on Mac OS X)

No



No

StageWebView shares cookies with URLLoader

Yes

No

Yes

StageWebView-set cookies are persisted across AIR applications

Yes

No

No

 

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License  Twitter™ and Facebook posts are not covered under the terms of Creative Commons.

Legal Notices   |   Online Privacy Policy