drag feedback is offset from cursor location when css pixels are scaled

RESOLVED FIXED

Status

()

Core
Drag and Drop
P4
normal
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: db48x, Assigned: Neil Deakin)

Tracking

({regression})

Trunk
x86
Linux
regression
Points:
---
Bug Flags:
blocking1.9 +
in-litmus ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

11 years ago
When I set the layout.css.dpi pref to 150 to make Firefox scale all css pixels to 2 device pixels, any drag feedback is offset from the correct cursor location. I haven't measured it, but it looks very much like the coordinates of the feedback are scaled by the same amount as the scaling caused by setting the pref.

During a discussion in #extdev, we were looking at http://mxr-test.landfill.bugzilla.org/mozilla/source/content/events/src/nsDOMUIEvent.cpp#116, which looks to me like it should return device pixels, not css pixels. On the other hand, that seems like it would cause the feedback to be offset in the other direction, so it could be unrelated. I haven't looked at how the feedback stuff works either.
(Reporter)

Comment 1

11 years ago
Another thing, the offset changes if it scales the feedback. It may be scaling the offset by the same amount as it scales the feedback.
(Assignee)

Comment 2

11 years ago
Doesn't seem to be a problem on Mac.
Is this still a problem?  And is it also a problem on full zoom?
Flags: blocking1.9?

Comment 4

11 years ago
re-nom if this is still an issue.  i'm not sure you really want to be changing that dpi setting.
Flags: blocking1.9?
The DPI setting just mimicks the effects of actually having that display resolution, so any problem it causes would also happen on high-res displays...
(Reporter)

Comment 6

11 years ago
This is definitely a regression due to the high-dpi scaling. Full page zoom has no effect on it, it only happens when the dpi is enough to cause the scaling (whether that's because you changed the pref, or because gecko inherited the dpi from the OS, which is how most people will stumble onto the problem.)
Flags: blocking1.9?
+'ing and setting as a P4.  
Flags: blocking1.9? → blocking1.9+
Priority: -- → P4
(Assignee)

Comment 8

11 years ago
Created attachment 294743 [details] [diff] [review]
convert screen coordinates into unscaled device pixels
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
Attachment #294743 - Flags: superreview?(roc)
Attachment #294743 - Flags: review?(roc)
+  if (aDOMNode) {

Make this an early return if (!aDOMNode)

+    if (document) {
+      nsIPresShell* presShell = document->GetPrimaryShell();
+      if (presShell) {

Early returns here too

I think that ConvertToUnscaledDevPixels should take a presshell or prescontext parameter. Ideally we would pass prescontexts/presshells around instead of getting them from the node, or at least get them from the node just once per drag API call.
Not for performance reasons, just because of code size and also flexibility so we're not depending on "one presshell per document" too much.
(Assignee)

Comment 11

11 years ago
Created attachment 295621 [details] [diff] [review]
address comments
Attachment #294743 - Attachment is obsolete: true
Attachment #295621 - Flags: superreview?(roc)
Attachment #295621 - Flags: review?(roc)
Attachment #294743 - Flags: superreview?(roc)
Attachment #294743 - Flags: review?(roc)
Attachment #295621 - Flags: superreview?(roc)
Attachment #295621 - Flags: superreview+
Attachment #295621 - Flags: review?(roc)
Attachment #295621 - Flags: review+
(Assignee)

Updated

11 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED

Updated

11 years ago
Flags: in-litmus?
Depends on: 411369

Updated

11 years ago
No longer depends on: 411369
You need to log in before you can comment on or make changes to this bug.