ICEfaces
  1. ICEfaces
  2. ICE-7319

ace:contextMenu renders outside of viewport

          Details

          • Type: Improvement Improvement
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: 2.1-Beta
          • Fix Version/s: 2.1-Beta2, 3.0
          • Component/s: ACE-Components
          • Labels:
            None
          • Environment:
            Tomcat 7.0.12
            ICEfaces-2.1.0.BETA-10022011-bin
          • Assignee Priority:
            P1

            Description

            In the Williams poc in screen1.xhtml remove everything below the master (first) ace:dataTable. Now alter the browser window so the bottom is at the bottom of the ace:dataTable. If you right-click to use the ace:contextmenu at the bottom of the ace:dataTable/browser window you will not see the menu because it renders below, where it is not visible to us.

            In this case ideally it should be rendered above the right click in the visible portion of the window.

              Activity

              Ascending order - Click to sort in descending order
              Hide
              Permalink
              yip.ng added a comment - - edited

              There seems to be two issue here:

              1. The menu should show at the pointer, but in our case is offset from the pointer.
              2. The menu doesn't flip around at the edge of the browser.

              We need to solve the first issue first.

              The second issue is not really an issue. It is the same behavior in PrimeFaces showcase. See screenshot-01.png. So it is probably expected behavior in jQuery menus. To flip the menu around is an enhancement. (Not trivial. And from past experiences, not guaranteed robust and cross-browser in all layout scenarios.)

              Show
              yip.ng added a comment - - edited There seems to be two issue here: 1. The menu should show at the pointer, but in our case is offset from the pointer. 2. The menu doesn't flip around at the edge of the browser. We need to solve the first issue first. The second issue is not really an issue. It is the same behavior in PrimeFaces showcase. See screenshot-01.png. So it is probably expected behavior in jQuery menus. To flip the menu around is an enhancement. (Not trivial. And from past experiences, not guaranteed robust and cross-browser in all layout scenarios.)
              Hide
              Permalink
              Ken Fyten added a comment -

              Note that the other menu types (menu, menuBar) all support this dynamic repositioning of the popup menu based on available space in the visible viewport, so this perhaps the technique they use could be incorporated into contextMenu.

              Show
              Ken Fyten added a comment - Note that the other menu types (menu, menuBar) all support this dynamic repositioning of the popup menu based on available space in the visible viewport, so this perhaps the technique they use could be incorporated into contextMenu.
              Hide
              Permalink
              yip.ng added a comment -

              Issue 1 is again caused by the "relative" position of the tabset. See screenshot-02.png. See also ICE-7256.

              Show
              yip.ng added a comment - Issue 1 is again caused by the "relative" position of the tabset. See screenshot-02.png. See also ICE-7256 .
              Hide
              Permalink
              yip.ng added a comment - - edited

              This is a bug in PF JS code.

              wijmo menu doesn't have a separate context menu, it just has a right click option to trigger the menu. wijmo itself doesn't set the position for you, probably their design is that a click may trigger a menu somewhere else, not necessarily at the mouse pointer.

              Also, the workings are different than the menu bar. In menu bar there is the root menu as the positioning context, and the positioning is also based on the super menu item, not the mouse pointer coordinates.

              In a context menu, all you have are mouse pointers, and mouse pointer coordinates are either based on the document or the window. There is no such thing as using an element as the positioning context for the mouse pointers.

              So PF tried to do the positioning themselves. In doing it they had the misconception like we had many times when developing our original old components: There is only one positioning context, the document, and all positioning is done with reference to the document. Instead of using jQuery positioning utilities, they also tried to reinvent the wheel and used the crude approach of manipulating the CSS top and left properties, without regard to cross-browser concerns.

              So with just the addition of the tabset as a positioning context, the code just broke right away.

              Fixed with another way of doing positioning using jQuery positioning utility, hopefully more robust and cross-browser. Tested: FF7, IE7, IE9, Chrome 14, Safari 5. See video at http://screencast.com/t/eAQC5eAtk5E.

              Revision: 25949

              Modified : /icefaces-ee/scratchpads/grimlock/icefaces/ace/component/resources/icefaces.ace/menu/menu.js

              Show
              yip.ng added a comment - - edited This is a bug in PF JS code. wijmo menu doesn't have a separate context menu, it just has a right click option to trigger the menu. wijmo itself doesn't set the position for you, probably their design is that a click may trigger a menu somewhere else, not necessarily at the mouse pointer. Also, the workings are different than the menu bar. In menu bar there is the root menu as the positioning context, and the positioning is also based on the super menu item, not the mouse pointer coordinates. In a context menu, all you have are mouse pointers, and mouse pointer coordinates are either based on the document or the window. There is no such thing as using an element as the positioning context for the mouse pointers. So PF tried to do the positioning themselves. In doing it they had the misconception like we had many times when developing our original old components: There is only one positioning context, the document, and all positioning is done with reference to the document. Instead of using jQuery positioning utilities, they also tried to reinvent the wheel and used the crude approach of manipulating the CSS top and left properties, without regard to cross-browser concerns. So with just the addition of the tabset as a positioning context, the code just broke right away. Fixed with another way of doing positioning using jQuery positioning utility, hopefully more robust and cross-browser. Tested: FF7, IE7, IE9, Chrome 14, Safari 5. See video at http://screencast.com/t/eAQC5eAtk5E . Revision: 25949 Modified : /icefaces-ee/scratchpads/grimlock/icefaces/ace/component/resources/icefaces.ace/menu/menu.js

                People

                • Assignee:
                  yip.ng
                  Reporter:
                  Brad Kroeger
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  0 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: