579492 - Full-page-zoom + dragging a selection --> dragged content is offset from cursor

Status: RESOLVED FIXED

(Core :: DOM: Copy & Paste and Drag & Drop, defect)

Description

[Daniel Holbert [:dholbert]]

STR:
 1. Load any site (e.g. http://ftp.mozilla.org/pub/mozilla.org/README )
 2. Select some text
 3. Click the selection and try dragging it around
     --> Note that the dragged selection stays "anchored" to your cursor
 4. Zoom in and repeat steps 2-3.
     --> Note that the dragged selection is offset to the upper-right.
 5. Zoom out and repeat steps 2-3.
     --> Note that the dragged selection is offset to the lower-left.

EXPECTED RESULTS:
Dragged content should stay anchored to cursor, even when you're zoomed.

ACTUAL RESULTS:
Dragged content is offset from cursor, as noted after steps 4 and 5.  (If you're zoomed a lot, it's offset a lot -- potentially even offscreen.)

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screencast of bug

Comment 2

[Daniel Holbert [:dholbert]]

Mozilla/5.0 (X11; Linux i686; en-US; rv:2.0b2pre) Gecko/20100715 Minefield/4.0b2pre

Comment 3

[Daniel Holbert [:dholbert]]

This is a regression w.r.t. Firefox 3.6.  WFM in a recent 3.6 nightly:
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.8pre) Gecko/20100722 Namoroka/3.6.8pre

 --> regression keyword, blocking request

Comment 4

[Alice0775 White]

Regression window:

Works:
http://hg.mozilla.org/mozilla-central/rev/8eabb8863ad6
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091117 Minefield/3.7a1pre ID:20091117123256

Fails:
http://hg.mozilla.org/mozilla-central/rev/fd765c193770
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091118 Minefield/3.7a1pre ID:20091118051933

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8eabb8863ad6&tochange=fd765c193770

Comment 5

[Daniel Holbert [:dholbert]]

Thanks Alice! In that pushlog, I'd most likely blame bug 528796 [1], which changed "nsIFrame::GetScreenRect()" to use CSS pixels instead of dev pixels.  (and zoom-level is one of the main differentiators between CSS vs dev pixels)

[1] http://hg.mozilla.org/mozilla-central/rev/0ccbfef948d5

Comment 6

[Daniel Holbert [:dholbert]]

Assuming comment 5 is correct, this bug's fix may be as simple as changing a particular nsIFrame::GetScreenRect() call to nsIFrame::GetScreenRectInAppUnits().

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to comment #6)
> This bug's fix may be as simple as changing a
> particular nsIFrame::GetScreenRect() call to
> nsIFrame::GetScreenRectInAppUnits().

Er, s/AppUnits/DevPixels/.  And yes, that does fix this!  (There isn't actually a GetScreenRectInDevPixels method, but we can synthesize the behavior we want from GetScreenRectInAppUnits & AppUnitsPerDevPixel.)

Patch coming in just a second.

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: fix: Make PresShell::PaintRangePaintInfo get screen rect in *dev* pixels

This patch makes us use dev pixels instead of css pixels.

The added code is exactly the same as the underlying GetScreenRect() implementation (the function call that I'm replacing), except that I've replaced CSSPixel with DevPixel.

Here's the GetScreenRect impl, for reference:
> 3634 nsIntRect nsIFrame::GetScreenRect() const
> 3635 {
> 3636   return GetScreenRectInAppUnits().ToNearestPixels(PresContext()->AppUnitsPerCSSPixel());
> 3637 }
http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsFrame.cpp#3634

Comment 9

[Daniel Holbert [:dholbert]]

http://hg.mozilla.org/mozilla-central/rev/e3a52188012c