bug:(@angular/cdk/drag-drop) - Incorrect item position when dragging item in <cdk-drop> - Safari Mobile

[kccsf]

Bug, feature request, or proposal:

Bug

What is the expected behavior?

When dragging an item, the dragged item should stay positioned directly beneath your finger (touch device).

What is the current behavior?

When zoomed into a web page (ie having pinched to zoom) on Safari mobile , the dragged item is positioned away from your finger. The higher the zoom level, the further away the dragged item is from your finger.

What are the steps to reproduce?

Behaviour can be seen in the 'Drag&Drop sorting' section after zooming in.
https://beta-angular-material-io.firebaseapp.com/cdk/drag-drop/examples

Which versions of Angular, Material, OS, TypeScript, browsers are affected?

@angular/cdk 7.0.0-beta.0
@angular/core 6.1.7
typescript 2.9.2
Safari Mobile on iPad A1893 running iOS 11.3.1 / 11.4.1

[crisbeto]

I believe this is the same issue as #10924. When the browser is zoomed in, it'll report different numbers to getBoundingClientRect and, as far as I'm aware, there's no way for us to account for it.

[kccsf]

I have this working using an idea found here (credit to the author):
https://stackoverflow.com/questions/52085998/how-to-position-a-fixed-location-element-on-ios-browser-when-zoomed

I do agree with his point that it feels pretty kludgey so the jury is out on whether you consider the method one that can be used. In case not but it helps others - here is some code (I was just editing drag-drop.es5.js directly whilst working on a solution):

Added the following function:

CdkDrag.prototype._setOffset =
    function () {
      this._offset = [0, 0];
      if (/iP(ad|hone|od).+Version\/[\d\.]+.*Safari/i.test(navigator.userAgent)) {
        var elem = document.createElement('div');
        document.body.appendChild(elem);
        elem.style.cssText = 'position:fixed; top: 0; left: 0;';
        var rect = elem.getBoundingClientRect();
        document.body.removeChild(elem);
        this._offset = [rect.left, rect.top];
      }
    };

Then called the function from _createPreviewElement prior to the (second) _setTransform (the one called due to there being no _previewTemplate).

The offset is then used in _setTransform:
element.style.transform = "translate3d(" + (x - this._offset[0]) + "px, " + (y - this._offset[1]) + "px, 0)";

Credits to the author of the device test I grabbed also:
https://coderwall.com/p/ktrbhq/detect-mobile-safari

This has been tested on:
iPad: iOS 9.2 /11.4.1
iPhone: iOS 10.3.3
Does not (I wouldn't expect it to due to the UA test) appear to have broken:
Safari: 11.0
Chrome (Windows): 68.0.3440.106 / 69.0.3497.92
Chrome (Android): 69.0.3497.91
Edge: 42.17134.1.0
FF Quantum: 62.0

[crisbeto]

Thanks for looking into it, but I'm not sure whether that's a feasible solution, because we'd have to do it every time you start dragging, otherwise we risk it being inaccurate, in addition to not being the cheapest calculation to make. I think that this is a non-issue, because responsive apps disable zooming anyway.

[kccsf]

No problem thank you for your help also. It does indeed need doing each time as zoom level could have changed. On the point of it being a non issue, perhaps not entirely as iOS 10+ ignores the ability to switch off zoom for accessibility (I appreciate hacks probably exist that curtail zoom actions, but the ethos behind the change is a valid one IMHO). https://webkit.org/blog/7367/new-interaction-behaviors-in-ios-10/ I appreciate it is a far from ideal solution but speaking personally, with no apparent side effects or lag it is a win for me as it enables me to use this great library for my clients who would expect it to work on iDevices regardless of zoom level. Perhaps a more economical solution exists to get the offset; if I think of one or see one in my travels I will report back!

…

On Sat, 15 Sep 2018, 10:12 Kristiyan Kostadinov, ***@***.***> wrote: Thanks for looking into it, but I'm not sure whether that's a feasible solution, because we'd have to do it every time you start dragging, otherwise we risk it being inaccurate, in addition to not being the cheapest calculation to make. I think that this is a non-issue, because responsive apps disable zooming anyway. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#13090 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AUEOvAhSzoo4fzBgPbInoDhQ7FYbRfm8ks5ubLZggaJpZM4WlHrB> .

[doublemcz]

I also experienced this issue when CSS zoom property is set to whenever but 1.

[mmalerba]

Closing as infeasible per the discussion above

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}