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.
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.msContentZoomFactorBTW. 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.