ICEfaces
  1. ICEfaces
  2. ICE-8869

ace:draggable - Can't drop a draggable ace:panel in Webkit browsers

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.2, EE-3.2.0.BETA
    • Fix Version/s: EE-3.2.0.GA, 3.3
    • Component/s: ACE-Components
    • Labels:
      None
    • Environment:
      Chrome, Safari
    • Assignee Priority:
      P1

      Description

      An ace:panel is set to be draggable. This panel displays an inner scrollbar due to the usage of :overflow:auto" (or scroll) CSS. In the Webkit browsers if the scrollbar is clicked it sticks the draggable panel to the mouse pointer and can't be dropped into the ace:droppable section.

      This issue does not occur in Firefox or IE browsers. If the image or main section of the panel is clicked first to drag then it works fine. Only an issue if the scrollbar is clicked to drag the panel.
      1. Case11873Example.zip
        31 kB
        Arran Mccullough
      2. Case11873ExampleWAR.zip
        9.35 MB
        Arran Mccullough

        Activity

        Hide
        Arran Mccullough added a comment -

        Support Case #11873

        Show
        Arran Mccullough added a comment - Support Case #11873
        Hide
        Arran Mccullough added a comment -

        Attached test case that shows issue.

        Steps:

        • Load welcomeICEfaces.jsf in Chrome/Safari
        • Click on the scrollbar section that is rendered below the car image.
        • Dragging does not occur but when the mouse is released the panel will be stuck to the mouse pointer.
        Show
        Arran Mccullough added a comment - Attached test case that shows issue. Steps: Load welcomeICEfaces.jsf in Chrome/Safari Click on the scrollbar section that is rendered below the car image. Dragging does not occur but when the mouse is released the panel will be stuck to the mouse pointer.
        Hide
        Arturo Zambrano added a comment -

        This issue is because Webkit browsers only fire onmousedown events on scrollbars, but they never fire onmouseup events on them, so they JQuery UI draggable behaviour can never know when the mouse has been released. This is a bug in Chrome that has been there for many years without getting fixed, as can be seen in this thread:

        http://code.google.com/p/chromium/issues/detail?id=14204

        The same bug has been reported several times to jQuery UI, but it has been closed as won't fix or as invalid, since it's not a jQuery problem per se, and there's nothing they can do about it:

        http://bugs.jqueryui.com/ticket/6925
        http://bugs.jquery.com/ticket/8184
        http://bugs.jqueryui.com/ticket/7935

        Likewise, we do not do any special handling in our code to cause this issue, neither jQuery UI does. So, this issue can't be fixed. The only thing that could be done is to simulate an onmouseup event on a subsequent onmousedown event that the user generates, which would fire only for Webkit browsers and only if the current state is 'dragging'. This has the only objective of avoiding getting stuck forever with the draggable item in some way, when clicking the scrollbars for dragging.

        Show
        Arturo Zambrano added a comment - This issue is because Webkit browsers only fire onmousedown events on scrollbars, but they never fire onmouseup events on them, so they JQuery UI draggable behaviour can never know when the mouse has been released. This is a bug in Chrome that has been there for many years without getting fixed, as can be seen in this thread: http://code.google.com/p/chromium/issues/detail?id=14204 The same bug has been reported several times to jQuery UI, but it has been closed as won't fix or as invalid, since it's not a jQuery problem per se, and there's nothing they can do about it: http://bugs.jqueryui.com/ticket/6925 http://bugs.jquery.com/ticket/8184 http://bugs.jqueryui.com/ticket/7935 Likewise, we do not do any special handling in our code to cause this issue, neither jQuery UI does. So, this issue can't be fixed. The only thing that could be done is to simulate an onmouseup event on a subsequent onmousedown event that the user generates, which would fire only for Webkit browsers and only if the current state is 'dragging'. This has the only objective of avoiding getting stuck forever with the draggable item in some way, when clicking the scrollbars for dragging.
        Hide
        Arturo Zambrano added a comment -

        Committed code, at revision 33080, to prevent getting stuck forever with the draggable when clicking on a scrollbar inside of it in Webkit and IE9 browsers. Since there can't be an ideal fix to this issue, we simply make sure the user doesn't stay stuck with the draggable when clicking a scrollbar inside of it. At the next click the user makes, the draggable will be released and back to its stationary state.

        It is also recommended, in cases where the draggable contains scrollbars, to use the 'handle' attribute in ace:draggable to specify a dedicated handle for dragging the element.

        Show
        Arturo Zambrano added a comment - Committed code, at revision 33080, to prevent getting stuck forever with the draggable when clicking on a scrollbar inside of it in Webkit and IE9 browsers. Since there can't be an ideal fix to this issue, we simply make sure the user doesn't stay stuck with the draggable when clicking a scrollbar inside of it. At the next click the user makes, the draggable will be released and back to its stationary state. It is also recommended, in cases where the draggable contains scrollbars, to use the 'handle' attribute in ace:draggable to specify a dedicated handle for dragging the element.
        Hide
        Cruz Miraback added a comment -

        Confirmed using icefaces3/trunk revision#33085 that the new behaviour described by Art occurs in Chrome, Safari, and IE9. I also checked that the behaviour of Firefox did not change as a result of the change.

        Show
        Cruz Miraback added a comment - Confirmed using icefaces3/trunk revision#33085 that the new behaviour described by Art occurs in Chrome, Safari, and IE9. I also checked that the behaviour of Firefox did not change as a result of the change.

          People

          • Assignee:
            Arturo Zambrano
            Reporter:
            Arran Mccullough
          • Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: