Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.8.2-EE-GA_P01
-
Fix Version/s: 1.8.3, 1.8.2-EE-GA_P02, 2.0.0
-
Component/s: ICE-Components
-
Labels:None
-
Environment:Linux dingbat 2.6.18-128.el5 #1 SMP Wed Jan 21 08:45:05 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
IE8
Description
We have an application that uses a ice:panelPopup to display a Popup Window which our user uses to enter search parameters. This searchDialog contains fields (into which search criteria is entered) and buttons... most important of which is the "search" button that runs the search. If an error occurs when running the search, a message is displayed in another ice:panelPopup. This is the scenario where we have panelPopups that are stacked on top of each other. The scenario is
1) Display the search popup
2) Enter criteria that causes an error and click the search button
3) An error message is displayed, in a new popup dialog that is visually "on top" of the search dialog. Click Ok to close the message dialog
4) Enter different criteria that will cause an error and click the search button.
5) An error message is displayed, in a new popup dialog that is visually "on top" of the search dialog.
In Firefox, this works fine. In IE (version 8), step 5 never occurs. Nothing visually happens until the user clicks a button to close the Search dialog. At this point, the second message dialog is visible. So, the second message dialog was displayed, but it was under the Search Dialog.
1) Display the search popup
2) Enter criteria that causes an error and click the search button
3) An error message is displayed, in a new popup dialog that is visually "on top" of the search dialog. Click Ok to close the message dialog
4) Enter different criteria that will cause an error and click the search button.
5) An error message is displayed, in a new popup dialog that is visually "on top" of the search dialog.
In Firefox, this works fine. In IE (version 8), step 5 never occurs. Nothing visually happens until the user clicks a button to close the Search dialog. At this point, the second message dialog is visible. So, the second message dialog was displayed, but it was under the Search Dialog.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Applied patch (small coding style modifications).
Show
Mircea Toma
added a comment - Applied patch (small coding style modifications).
Applied patch to ICEfaces2.0/compat as well.
Show
Mircea Toma
added a comment - Applied patch to ICEfaces2.0/compat as well.
There is a regression in ICEfaces 2 compat/component-showcase now. When you close a modal popup, the modal layer is never removed. Works fine in icefaces/trunk though (1.x).
Changed code from calling Array.isEmpty missing function.
Show
Mircea Toma
added a comment - Changed code from calling Array.isEmpty missing function.
We found the problem to be in bridge/lib/extras/style.js file, and how it was managing the z-index values of the running variable. In the Ice.modal Javascript class, it was defining a Javascript object called "running". The running object was used to track the running modal dialogs, in order to define their zIndex setting. It was using a for loop to go through the entries in running, returning the last one as the last modal popup on the stack.
The issue is there is no guarantee that the order in which attributes are defined for a Javascript object will be preserved when they are retrieved. It looks like the implementation in Firefox preserves this order (using something like an array list), but IE does not.
This patch changes the running variable from a Javascript object to an Array, and the position in the array defines the order in which the modal dialogs were displayed.
This has worked for us. Please consider this as a starting point for fixing this in a future release.