ICEfaces
  1. ICEfaces
  2. ICE-3457

panelPositioned in scollable div causes unexpected behavior

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: 1.7.1
          • Fix Version/s: 1.8
          • Component/s: ICE-Components
          • Labels:
            None
          • Environment:
            All

            Description

            When a panelPosition is located inside a scrollable div there is unexpected behavior with the dragging and dropping of items. There is no problem when the div is scrolled to the top but if you scroll to the bottom and try and drag an item the empty space it renders is not in the correct position. It looks like the drag and drop mechanism doesn't take into account the scrolled offset.

              Activity

              Ascending order - Click to sort in descending order
              Arran Mccullough created issue -
              Arran Mccullough made changes -
              Field Original Value New Value
              Priority Major [ 3 ] Minor [ 4 ]
              Support Customer Ref. #s https://www.icesoft.ca:4443/supportilla/show_bug.cgi?id=5136
              Hide
              Permalink
              Arran Mccullough added a comment -

              Attached screen shot of issue, test case code, and built war file for testcase (Built to run on NetBeans 6.x).

              Show
              Arran Mccullough added a comment - Attached screen shot of issue, test case code, and built war file for testcase (Built to run on NetBeans 6.x).
              Arran Mccullough made changes -
              Attachment panelPositioned-issue.JPG [ 11206 ]
              Attachment testPanelPositioned.zip [ 11207 ]
              Attachment Case5136Example.war [ 11208 ]
              Hide
              Permalink
              Arran Mccullough added a comment -

              Comment from support customer:

              The strange behavior also occurs when the panelPositioned is placed in a DIV (container) that is not scrollable but this DIV is placed in a parent DIV that is scrollable. So you could have:

              DIV (scrollable content)

              __ice:PanelGroup (fixed content)
              __ice:panelCollapsible (fixed content)
              __ice:panelPositioned

              I guess your developers should care about the offsets of all scrollable parent containers in the hierarchy not only the immediate parent DIV.

              Show
              Arran Mccullough added a comment - Comment from support customer: The strange behavior also occurs when the panelPositioned is placed in a DIV (container) that is not scrollable but this DIV is placed in a parent DIV that is scrollable. So you could have: DIV (scrollable content) __ice:PanelGroup (fixed content) __ice:panelCollapsible (fixed content) __ice:panelPositioned I guess your developers should care about the offsets of all scrollable parent containers in the hierarchy not only the immediate parent DIV.
              Arran Mccullough made changes -
              Priority Minor [ 4 ] Major [ 3 ]
              Ken Fyten made changes -
              Fix Version/s 1.8DR#2 [ 10142 ]
              Assignee Yip Ng [ yip.ng ]
              Hide
              Permalink
              Ken Fyten added a comment -

              Similar issue to ICE-3287.

              Show
              Ken Fyten added a comment - Similar issue to ICE-3287 .
              Hide
              Permalink
              John Genoese added a comment -

              This issue is an absolute show-stopper for me. I need to drop various GUI objects on an <ice:tree/>, which is embedded in a <div/> with "overflow:scroll". The drop target tree node is always identified as if the tree view <div/> is scrolled to the top. I will happily attach the test case I prepared, if requested.

              I apologize for pushiness, but can anyone provide a time-frame for the fix? I need to know because a critical portion of my app is completely dependent on this working correctly.

              Show
              John Genoese added a comment - This issue is an absolute show-stopper for me. I need to drop various GUI objects on an <ice:tree/>, which is embedded in a <div/> with "overflow:scroll". The drop target tree node is always identified as if the tree view <div/> is scrolled to the top. I will happily attach the test case I prepared, if requested. I apologize for pushiness, but can anyone provide a time-frame for the fix? I need to know because a critical portion of my app is completely dependent on this working correctly.
              Ken Fyten made changes -
              Fix Version/s 1.8DR#3 [ 10143 ]
              Fix Version/s 1.8DR#2 [ 10142 ]
              Ken Fyten made changes -
              Fix Version/s 1.8 [ 10161 ]
              Fix Version/s 1.8RC1 [ 10143 ]
              Ken Fyten made changes -
              Salesforce Case []
              Assignee Priority P2
              Assignee Yip Ng [ yip.ng ] Arturo Zambrano [ artzambrano ]
              Ken Fyten made changes -
              Fix Version/s 1.8RC2 [ 10163 ]
              Fix Version/s 1.8 [ 10161 ]
              Ken Fyten made changes -
              Salesforce Case []
              Fix Version/s 1.8 [ 10161 ]
              Fix Version/s 1.8RC2 [ 10163 ]
              Repository Revision Date User Message
              ICEsoft Public SVN Repository #18631 Mon Mar 23 10:27:32 MDT 2009 art.zambrano ICE-3457 panelPositioned in scrollable div causes unexpected behavior
              Files Changed
              Commit graph MODIFY /icefaces/trunk/icefaces/bridge/lib/scriptaculous/dragdrop.js
              Repository Revision Date User Message
              ICEsoft Public SVN Repository #18634 Mon Mar 23 11:22:13 MDT 2009 art.zambrano ICE-3457 (added comments)
              Files Changed
              Commit graph MODIFY /icefaces/trunk/icefaces/bridge/lib/scriptaculous/dragdrop.js
              Hide
              Permalink
              Arturo Zambrano added a comment - - edited

              fixed at revision 18631

              EDIT: It's important to note that this fix lies in the original scriptaculous code. We need to make sure to include this fix whenever we update the scriptaculous library (unless this issue comes already solved in new versions).

              Show
              Arturo Zambrano added a comment - - edited fixed at revision 18631 EDIT: It's important to note that this fix lies in the original scriptaculous code. We need to make sure to include this fix whenever we update the scriptaculous library (unless this issue comes already solved in new versions).
              Arturo Zambrano made changes -
              Status Open [ 1 ] Resolved [ 5 ]
              Resolution Fixed [ 1 ]
              Ken Fyten made changes -
              Assignee Priority P2
              Ken Fyten made changes -
              Status Resolved [ 5 ] Closed [ 6 ]
              Assignee Arturo Zambrano [ artzambrano ]
              Hide
              Permalink
              Shobhit Gupta added a comment -

              Is this issue really solved in 1.8 version ?

              Show
              Shobhit Gupta added a comment - Is this issue really solved in 1.8 version ?
              Hide
              Permalink
              Joanne Bai added a comment -

              QA verified the fix again on ICEfaces trunk revision 18864

              Test app has been added to the QA repo

              Show
              Joanne Bai added a comment - QA verified the fix again on ICEfaces trunk revision 18864 Test app has been added to the QA repo

                People

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

                  Dates

                  • Created:
                    Updated:
                    Resolved: