Blackberry OS6 version will not be completed.

• Navigation and connection management in the existing container are handled through the BrowserFieldConnectionManager and BrowserFieldCookieManager classes. These objects do not expose any IO stream for the purposes of duplicating the Android writing or reading input stream.

• It is possible to duplicate this structure if you take over handling the socket connections, but that exposes you to the inane world of Blackberry connection management which is beyond the scope of this container.

A document describing this world can be found here: http://supportforums.blackberry.com/t5/Java-Development/Different-ways-to-make-an-HTTP-or-socket-connection/ta-p/445879

• There is a BrowserField onDocumentProgress callback, but it is poorly behaved in an Ajax environment. Progress events are received, but no onDocumentLoaded event to conclude the download is received. If an updated region contains multiple resources, the progress events are impossible to consolidate into any meaningful 'update'

iOS implementation is complete, making use of a thin progress bar just below the status icons. To override this implementation and customize via ice.progress, return true from a custom ice.progress implementation.

Android implementation complete, so passing along for iOS work. Android uses an overlay progress bar at the bottom of the header area to show progress for all network interactions.

Changes are checked in to r34370.

The attached APK contains a prototype of a status bar overlay for Android container. It seems pretty effective, but there are some obvious questions:

Where should we put it? Should its position be configurable from the page?

I tried making it disappear after the page loaded, but that seemed more distracting.

I have not checked anything in at this point, as we should decide where to go with this.

Worth considering for 1.3 if time permits.