getScreenCTM incorrectly affected by pinch zoom

Issue #14429296 • Assigned to bbrinza

Details

Author
Philipp K.
Created
Oct 29, 2017
Privacy
This issue is public.
Found in
  • Microsoft Edge
  • Internet Explorer
Found in build #
16.16299
Reports
Reported by 2 people

Sign in to watch or report this issue.

Steps to reproduce

When pinch zooming a page (not to be mixed up with classic page zooming which e.g. can be triggered through Ctrl + +/-), i.e. the visual viewport gets changed (as opposed to the layout viewport with classical zooming) then this changes the matrix returned from calls to getScreenCTM() Microsoft Edge (and IE11).

This behaviour is different from Google Chrome and it breaks libraries like d3.js (see https://github.com/d3/d3-drag/issues/43).

Attached is a simple demo showing the getScreenCTM() values of a <g> element. Observe how a pinch-zoom causes some of these values to change in Microsoft Edge while this is not the case in Google Chrome.

Attachments

Comments and activity

  • Microsoft Edge Team

    Changed Assigned To to “Steven K.”

    Changed Assigned To to “bbrinza”

  • The issue even shows in Microsoft’s own demo (at least occasionally, I haven’t yet figured out when exactly): http://samples.msdn.microsoft.com/Workshop/samples/svg/coordinateTransforms/liquidSVG.html (Compare the displayed coordinates of e.g. various cutting points the default at various pinch zoom levels [again, not to be mixed up with page zoom].)

  • Whether pinch zoom is in effect can be checked through document.documentElement.msContentZoomFactor BTW. Now I would just need some workaround, would it be maybe possible to use this and possibly other values to calculate the unzoomed value? If this bug does not get fixed soon (and certainly not IE11) could we instead please get some help concerning a workaround?

  • I just took a quick look, it looks like the issue is that the value returned does not take in consideration the scroll position resulting from the scrollbars created due to the content pitch-zooming (there is also a content zooming impact, but it might be by design, I’m not sure).

    If this assumption is correct, I think the solution would be to use window.scrollX window.scrollY and document.documentElement.msContentZoomFactor to get an interoperable value in that case. 

    In the attached workaround, I was a bit lazy and decided to go with a solution that gets the value of the CTM corrections using four “marker” svg nodes on the edges of the screen, but I’m sure you will find this is not necessary if you investigate the exact relationship of these values and scrollX/Y and msContentZoomFactor.

    Please verify that the value you receive is incorrect before applying the fix, otherwise your application might break when we decide to fix this issue in a future version of Edge.

You need to sign in to your Microsoft account to add a comment.

Sign in