When a .svg file is is panned in chromium (using shift+right-click+drag), the vertical motion is reversed from the mouse motion. This operation works as expected on Safari, so a mechanism is needed to specify which sense to use for the different ports.
Created attachment 104063 [details] Proposed fix + test
My understanding is that we already have a mechanism for converting between the coordinate spaces (windowToContents). Check out the patch in https://bugs.webkit.org/show_bug.cgi?id=65800 which makes use of this, and if you have a chance, build it with Chromium and see why it doesn't pass the test there. I'd prefer that patch to this one because it seems unfortunate to keep track of this information in different places, especially because it's different between different platforms *and* frontends.
(In reply to comment #0) > When a .svg file is is panned in chromium (using shift+right-click+drag), the vertical motion is reversed from the mouse motion. This operation works as expected on Safari, so a mechanism is needed to specify which sense to use for the different ports. I will note that it no longer works correctly in the latest shipping version of Safari on OS X.
(In reply to comment #2) > My understanding is that we already have a mechanism for converting between the coordinate spaces (windowToContents). Check out the patch in https://bugs.webkit.org/show_bug.cgi?id=65800 which makes use of this, and if you have a chance, build it with Chromium and see why it doesn't pass the test there. > > I'd prefer that patch to this one because it seems unfortunate to keep track of this information in different places, especially because it's different between different platforms *and* frontends. I was unaware of windowToContents, but the patch you mention does resolve the issue. Presumably we should mark this bug as a duplicate, and proceed with https://bugs.webkit.org/show_bug.cgi?id=65800.
*** This bug has been marked as a duplicate of bug 65800 ***
(In reply to comment #4) > I was unaware of windowToContents, but the patch you mention does resolve the issue. Presumably we should mark this bug as a duplicate, and proceed with https://bugs.webkit.org/show_bug.cgi?id=65800. Seems like the right thing to do, to me! If you could run the test with pixel results on and send me the chromium result, I'd love to see why it differs, but haven't had the time to set up a Chromium build.