RESOLVED DUPLICATE of bug 65800 66315
[chromium] SVG pan updates have wrong vertical sense
https://bugs.webkit.org/show_bug.cgi?id=66315
Summary [chromium] SVG pan updates have wrong vertical sense
W. James MacLean
Reported Tuesday, August 16, 2011 6:18:26 PM UTC
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.
Attachments
Proposed fix + test (6.56 KB, patch)
2011-08-16 10:19 PDT, W. James MacLean
no flags
W. James MacLean
Comment 1 Tuesday, August 16, 2011 6:19:16 PM UTC
Created attachment 104063 [details] Proposed fix + test
Tim Horton
Comment 2 Tuesday, August 16, 2011 6:23:15 PM UTC
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.
Tim Horton
Comment 3 Tuesday, August 16, 2011 6:23:48 PM UTC
(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.
W. James MacLean
Comment 4 Tuesday, August 16, 2011 7:25:52 PM UTC
(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.
W. James MacLean
Comment 5 Tuesday, August 16, 2011 7:26:27 PM UTC
*** This bug has been marked as a duplicate of bug 65800 ***
Tim Horton
Comment 6 Tuesday, August 16, 2011 7:28:16 PM UTC
(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.
Note You need to log in before you can comment on or make changes to this bug.