WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
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.
Top of Page
Format For Printing
XML
Clone This Bug