There is an error in the Bridge before it even gets to the calendar JS. See screenshot-01.png

The reason the dateTimeEntry doesn't pop up is because the mandatoryResourceConfig in the test is configured incorrectly, it is set to '@all' when it should just be 'all'. If changing the mandatoryResourceConfig to the correct value the test works fine. This was tested on icefaces3/trunk revision#31304. Attached rar containing the correct source.

Assignee: Ken Fyten (was: Mircea Toma)
Assignee Priority: (was: P1)
Resolution: Invalid
Seems this issue is resolved by the correct use of the mandatoryResource Configuration mechanism to ensure the necessary ace:dateTimeEntry resources are preloaded when necessary, as is the case in this scenario.
Note that it is more efficient to specify just the component that is being loaded dynamically in the mandatoryResource config, instead of 'all'.
See the http://wiki.icesoft.org/display/ICE/ACE+Configuration Wiki topic for more information on the use of mandatoryResource Config.

The correct use of the mandatoryResource configuration, resolves the initial loading of the component, however the popup calender does not render if the page was internally navigated away from, and then back to (as if a user were to go back a step in a multi-page process)
To replicate:
Click Navigate Internally from Index --> use date component (it works) --> click tab2 --> Click the commandButton 'Navigate Internally' --> (This loads a different xhtml page internally) --> click commandButton 'Navigate back Internally to date component' --> This reloads the original tabSet containing the date component (The calender popup no longer works)
This was tested at 3.2Beta1, with the mandatoryResourceConfiguration set to 'all' at the application level.

Assignee: yip.ng (was: Ken Fyten)
Assignee Priority: P1
I'd updated original test case based on the comments from Michael and was able to reproduce it.

Assigning to Yip for further review. The bug is critical for our customer.
(Restricted to icesoft-internal-developers group)

After much tracing and debugging, found that there is nothing wrong with the component.
This is yet another case of the same old issue of the framework DOM updates messing up the client-side states.
The popup is created dynamically on the client side. (It is a div attached to the body.) Seems the popup is shared among calendar instances. The calendar instances and the shared popup are managed by a singleton manager. In this scenario the framework just comes along and wipe out the whole body, without the manager knowing.
This can't just be solved like before using a hash code to force DOM diff. to update properly. You need to tell the manager you are wiping out HTML under its control. Even then there may not be an easy fix. Seems the manager works by assuming that the popup is created/initialized only once per jquery-ui.js load, i.e. the framework needs to reload jquery-ui.js or at least the datepicker portion of the jquery-ui.js.
Tried hardcoding to force manager to re-create the popup for the second calendar instance in this scenario and it seemed to work. See video http://screencast.com/t/K0M6bqnF. Need to find a way to make this work without creating a host of other problems in this or other scenarios.

Tested wrapping group panel with common id as mentioned by Mark. Working.

Another similar case: http://jforum.icesoft.org/JForum/posts/list/15/21571.page#76150.

ICE-8970, ICE-9455.