dd-gestures inclusion makes DD.Drag select page text during the drag action

[opichals]

I believe the issue came in http://yuilibrary.com/projects/yui3/ticket/2532718 bugfix. The fix moves the preventDefault handling from 'mousedown' to 'mousemove' to enable click handling on DD.Drag instances. However the mousemove handler calls DDM._move via Y.throttle and therefore selection and other DOM default actions are handled in the throttled-out occurences.

I have worked around that using the following patch, but I am not sure that would not cause other side-effects in other D&D use-cases. Please review.

diff --git a/html/lib/yui/3/build/dd-gestures/dd-gestures.js b/html/lib/yui/3/build/dd-gestures/dd-gestures.js
index dfe2762..2e617f2 100644
--- a/build/dd-gestures/dd-gestures.js
+++ b/build/dd-gestures/dd-gestures.js
@@ -51,7 +51,10 @@ YUI.add('dd-gestures', function (Y, NAME) {

         this._createPG();
         this._active = true;
-        Y.one(Y.config.doc).on('gesturemove', Y.throttle(Y.bind(DDM._move, DDM), DDM.get('throttleTime')), { standAlone: true });
+        Y.one(Y.config.doc).on('gesturemove', Y.throttle(Y.bind(DDM._move, DDM), DDM.get('throttleTime')), {
+            standAlone: true,
+            preventDefault: true
+        });
     };

[rgrove]

@opichals This is the fix I would recommend. I recently had the same issue with a separate drag and drop library I'm working on, and this was the solution.

[opichals]

It's just that the dd-ddm::_move method does not always call preventDefault() while this patch would prevent it for every occurrence.

[opichals]

Also our QA found the suggested solution doesn't work in FF 20. So I opted to to roll my dd-* modules back to version 3.7.1 which we upgraded from. This seems to be working as expected so far.

So in my eyes the http://yuilibrary.com/projects/yui3/ticket/2532718 bugfix introduced quite a nontrivial regression.

[andrewnicols]

Hi all,

We're seeing this issue. What's the chance of it getting some kind of fix integrated for this?

@opichals, what issues were you seeing on FF20?

[andrewnicols]

Pull request submitted in #1557

[tilomitra]

@andrewnicols @rgrove @opichals The proposed fix that we merged in breaks page scrolling due to the document listening to gesturemove and preventing default browser behavior.

You can see this by going to http://yuilibrary.com/yui/docs/dd/groups-drag.html on a touch-enabled device and trying to scroll the page.

I agree that we need the preventDefault() in there to prevent text selection, but doing it on the entire document is too heavy-handed.

[tilomitra]

@clarle and I were thinking that instead of using e.preventDefault(), we can use CSS3 user-select to prevent text selection (that's the end goal, right?)

Here's how it can work:

• On gesturemovestart, add user-select styles to the boundingBox of the draggable area. This will ensure that none of the children have a visible text selection.
• Remove the styles on gesturemoveend. (or not. we may want these styles to be permanently set on the boundingBox. What do you guys think?)

This way, you don't need preventDefault and you don't get text selection either. The one caveat when it comes to user-select is that IE is not supported, but since this is in dd-gestures and the problem is specifically with touch input, this isn't a big deal.

I came up with a very rough proof of concept to test if this would work. I basically changed the gesturemove event handler to this:

        Y.one(Y.config.doc).on("gesturemove", function (e) {
            DDM._move(e);
            e.currentTarget.setStyles({
                "-khtml-user-select": "none",
                "-moz-user-select": "none",
                "-ms-user-select": "none",
                 "user-select": "none",
                "-webkit-touch-callout": "none",
                "-webkit-user-select": "none"
            });
        }, {standAlone: true});

Again, we wouldn't want to set styles on gesturemove and we wouldn't want to have this CSS written in JS, but this worked so I think this solution may have legs. Let me know what you guys think.

[andrewnicols]

For reference, this is the original issue we had reported: https://tracker.moodle.org/browse/MDL-42409

I've just installed the android sdk and used avd to replicate on a generic tablet.

Before the first patch, drag/drop is completely unreliable; afterwards it seems to work well. However, the stock Android browser is now blocked from other touch events - e.g. using gestures to move the page.

I've put a video up at https://www.youtube.com/watch?v=yc-MhA4g9v0 showing:

• state of drag/drop at 3.15.0:
  ** drag/drop works, and reliably, but it's not possible to change the page position;
• state of jquery drag/drop on android for comparison (not working at all); and then
• reverting the patch introduced in dd-gestures inclusion makes DD.Drag select page text during the drag action #693
• state of drag/drop with the patch reverted.

Suffie to say, none of the above performs well at all (not even jQuery).

[tilomitra]

Thanks @andrewnicols the video helps. So looks like we have two problems:

1. If we use {preventDefault: true} then the page can't scroll which is a bit of a deal-breaker.
2. If we don't have {preventDefault: true}, then the page isn't usable in Android, which is also a deal-breaker.

I'll look into it to see what else we can do. I have an Android tablet that I can test on, so maybe my results will vary.