Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 1.8.2-EE-GA_P01
-
Fix Version/s: 1.8.2-EE-GA_P02
-
Component/s: ICE-Components
-
Labels:None
-
Environment:IE8, ICEfaces EE 1.8.2_P01
-
Workaround Exists:Yes
-
Workaround Description:
Description
This issue occurs in IE8 only and with ICEfaces EE 1.8.2_P01.
This issue can be reproduced using the component showcase demo. If the browser view is scrolled and a value is entered into the input field the drop down list is displayed in the wrong position. If the browser is not scrolled then the drop down displays properly. Also if the browser is set to use compatibility mode then the drop down displays in the proper position.
This issue can be reproduced using the component showcase demo. If the browser view is scrolled and a value is entered into the input field the drop down list is displayed in the wrong position. If the browser is not scrolled then the drop down displays properly. Also if the browser is set to use compatibility mode then the drop down displays in the proper position.
We came across something similar with the SelectInputDate components in 1.8.2. EE P01. Whenever we have SelectInputDate components in scrollable divs (or, more commonly in our application, nested scrollable divs), the positioning of the popup calendar was not correct. From what we could see, it wasn't taking into account any offsets incurred by the scrollable area.
We also wanted to handle being able to position the popup in relatively-positioned divs (as in ICE-4026). We had these same issues with other dynamically positioned components (autoComplete lists, popup menus and dropdown menus in addition to the popup calendar).
To address these issues for the SelectInputDate component, we updated the SelectInputDate renderer, so that we could provide our own javascript logic in order to calculate the positioning ourselves. I've attached the patch containing these changes (against 1.8.2 EE P01).
We could address the other components by extending the existing renderers, without making any modifications to those renderers.
I'm attaching this to this issue because it sounds similar to what we were experiencing. Can you please check that the changes already applied to this issue also help with SelectInputDate components as well? If they do not, can you consider the attached patch so we can continue providing our own javascript logic.