A very subtle problem with many facets.
If we are using the Blackberry container and we load a new page of content using a 'GET' request, the functions and variables defined in the javascript namespaces disappear exactly 1 minute 30 seconds afterward.

Disappearing namespace functions:
- Once the condition occurs, the buttons in the container are essentially dead. All of the components using native javascript extensions are unresponsive, as well as navigation links using <h:commandLink> tags, which resolve to icefaces.upload javascript calls.
- I extended the container to contain a logging function in javascript so the javascript layer can send log messages to the Blackberry log. Also, I have a test function in blackberry-interface.js that checks the existence of symbols in the icefaces and ice namespace. When the condition occurs, the javascript test function doesn't log anything at all, yet nor does executing it throw an exception.

Reloading the page:
The development code and samples constantly show using the requestContent method on the BrowserField object. However, in the javadoc, it says that 'typically, this method will only be called once'. The Blackberry container exposes a loadPage(url) method that is used by the back, home, and reload functions. The Blackberry BrowserField history manager doesn't support retrieving the locations as an array (which precludes using it to populate the dialog) so I had implemented a HistoryManager to do this, and all three of these functions used the loadPage method which was using requestContent.

The Test Case:
I've built a smaller version of the container application that is modelled on the original. It starts in the same way, constructs the BrowserField and BrowserField management classes in the same way, and loads the blackberry-interface and javascript extensions in the same way. The test application works, and doesn't exhibit the symptoms. It serves to show that the BrowserField isn't very sensitive to how the content is loaded. For example, there are multiple ways to reload content:
- BrowserField.refresh()
- BrowserFieldHistory.refresh();
- BrowserField.requestContent( currentURL);

and in the test container, all of these work and don't stomp over the javascript. The main similarities/differences between the applications are:

1) Eula viewing is different
2) Browser field instantiation is the same.
3) BrowserFieldListener setup and registration is the same
4) blackberry-interface.js invocation is the same (inserting script node as child of head)
5) ParkPushIds invocation is different
6) Options are different
7) BIS Push registration is different.
8) Application indicator is different.


One other thing that is different is the size of the classes used in the javascript extension. We load several classes for camera/video/audio that are quite large. I have loaded an equal number of temporary classes as javascript extensions.

There are no timers used in the code. To reproduce, all you have to do is start the container and navigate to mobile showcase and press reload. At this stage, all of the javascript extensions have been registered, but only the blackberry ajaxUpload extension will have been used.

I've registered listeners for BrowserField errors, as well as Low memory listeners, but these dont shw anything amiss.


This bug is noticeable in that once you navigate using GET, you will experience a loss of function 1:30 later, and the workaround is to reload the page. Once you reload the page, the symptom will surface 1:30 later, repeat. If you do not navigate using 'GET', the application will continue to work normally for as long as you both don't use 'GET' and the session doesn't expire. This is what has lead to various mystery appearances of the issue.