ICEfaces
  1. ICEfaces
  2. ICE-5622

selectInputText drop down renders in wrong position when page is scrolled in IE8

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major 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:
            Hide
            Set IE8 to use compatibility mode using the following meta-tag in the head section of the page(s):

            <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
            Show
            Set IE8 to use compatibility mode using the following meta-tag in the head section of the page(s): <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

            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.

              Activity

              Ascending order - Click to sort in descending order
              Hide
              Permalink
              Isuru Perera added a comment -

              I also have this issue in ICEfaces EE 1.8.2_P01 with auto-complete list position.

              Please see this: http://www.icefaces.org/JForum/posts/list/16636.page

              My forum post explains the issue in detail.

              Thanks.

              Show
              Isuru Perera added a comment - I also have this issue in ICEfaces EE 1.8.2_P01 with auto-complete list position. Please see this: http://www.icefaces.org/JForum/posts/list/16636.page My forum post explains the issue in detail. Thanks.
              Hide
              Permalink
              yip.ng added a comment - - edited

              Reverting as described in forum will fix this and won't affect ICE-5465 for IE7 (original reported issue), but the ICE-5465 test case will fail (in a different way than original reported problem for IE7) for IE8. See videos at ICE-5465. Still can't find a fix for this.

              Show
              yip.ng added a comment - - edited Reverting as described in forum will fix this and won't affect ICE-5465 for IE7 (original reported issue), but the ICE-5465 test case will fail (in a different way than original reported problem for IE7) for IE8. See videos at ICE-5465 . Still can't find a fix for this.
              Hide
              Permalink
              yip.ng added a comment -

              Fix checked into trunk. Tests also done with test cases for ICE-4974 and ICE-5465.

              Show
              yip.ng added a comment - Fix checked into trunk. Tests also done with test cases for ICE-4974 and ICE-5465 .
              Hide
              Permalink
              Ed Hillmann added a comment -

              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.

              Show
              Ed Hillmann added a comment - 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.

                People

                • Assignee:
                  Unassigned
                  Reporter:
                  Arran Mccullough
                • Votes:
                  2 Vote for this issue
                  Watchers:
                  2 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: