1521630 - Cannot use mouse drag to select characters on Google search box when window manager has double DPI setting

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Steps to reproduce:

1. Goto https://www.google.com/search?q=abcdefghijklmnopqrstuvwxyz. The search box contains "abcdefghijklmnopqrstuvwxyz". (The string doesn't matter, but it seems easier to reproduce with a long string.)
2. Place the caret (cursor) between "v" and "w", e.g. abcdefghijklmnopqrstuv|wxyz
3. Drag the mouse from the cursor to the left to select some characters.

Expected result:
The characters can be selected.

Actual results:
The characters cannot be selected. Instead, the entire Firefox window is being dragged.

Comment 1

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Tim, mozregression told me that bug 1241885 might cause this regression. Do you mind take a look?

Comment 2

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

FWIW, I use Linux Mint 19 Tara, and reproduce this on Nightly 2019-01-21.

Comment 3

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Attachment: try_to_select_text.mkv

This is the screencast to select the text.

I find the key to reproduce this bug is that I have the screen resolution 3840x2160 and my user interface scaling set to "Double (Hi-DPI)". I cannot reproduce this on Normal DPI settings on either 3840x2160 or 1920x1080 resolutions.

This article might be helpful for changing DPI on Ubuntu.
https://askubuntu.com/questions/472262/adapt-ubuntu-to-a-high-dpi-resolution-screen

Comment 4

[Tim Nguyen :ntim]

So, I haven't been able to follow the instructions for Ubuntu (it seems like VMWare is forcing down the DPI settings).

Martin, Do you think the event coordinates in the GTK code might be wrong with high DPI ? or do you see any other possible causes that might be obvious ?

Comment 5

[Tim Nguyen :ntim]

Should this be aEvent->x_root/y_root instead of aEvent->x/y ?

Comment 6

[Martin Stránský [:stransky] (ni? me) (PTO, Back Jun 24)]

(In reply to Tim Nguyen :ntim from comment #5)

Should this be aEvent->x_root/y_root instead of aEvent->x/y ?

330daedbeac2bba296d663668e0e0cf248bc6823/widget/gtk/nsWindow.cpp#2568

I don't think so. The aEvent->x/y are relative to window corner as well as the dragable region. aEvent->x_root/y_root are relative to screen corner and depend on actual window position.

Unfortunately high-DPI does not work well in X11 and you need high density monitor to test that, with DPI > 196 or so. The screen scale does not work on x11 for low-DPI monitors.

Comment 7

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Re comment 5:

I know nothing about GTK and window code, but I hack it by replacing

mDraggableRegion.Contains(aEvent->x, aEvent->y)

with

auto p = GetRefPoint(this, aEvent);
mDraggableRegion.Contains(p.x, p.y)

And it fixed the bug for me. GetRefPoint seems to take the DPI into account and is used by serveral places in nsWindow.

On my Double DPI setting, p is twice as large as aEvent->x, y. For example when aEvent->x/y = (309,121.5), p = (618,243). Under normal DPI setting, both are the same.

I wonder if this makes sense?

Comment 8

[Tim Nguyen :ntim]

(In reply to Ting-Yu Lin [:TYLin] (UTC-8) from comment #7)

Re comment 5:

I know nothing about GTK and window code, but I hack it by replacing

mDraggableRegion.Contains(aEvent->x, aEvent->y)

with

auto p = GetRefPoint(this, aEvent);
mDraggableRegion.Contains(p.x, p.y)

And it fixed the bug for me. GetRefPoint seems to take the DPI into account and is used by serveral places in nsWindow.

On my Double DPI setting, p is twice as large as aEvent->x, y. For example when aEvent->x/y = (309,121.5), p = (618,243). Under normal DPI setting, both are the same.

I wonder if this makes sense?

Thanks for looking into this! The other possible fix I was thinking of was using event.mRefPoint.x and event.mRefPoint.y (taking the WidgetMouseEvent coordinate instead of the GdkEventButton coordinates). But using the GdkEventButton coordinates with GetRefPoint() seems better here (since WidgetMouseEvent coordinates might be compressed).

Martin, what do you think ?

Comment 9

[Martin Stránský [:stransky] (ni? me) (PTO, Back Jun 24)]

I can reproduce it on Wayland/scale factor 2 so it a general issue. I'll look at it.

Comment 10

[Martin Stránský [:stransky] (ni? me) (PTO, Back Jun 24)]

Attachment: Bug 1521630 [Linux/Gtk] Use GdkEventCoordsToDevicePixels() to get mouse coordinates for mDraggableRegion.Contains(), r=ntim

Comment 11

[Martin Stránský [:stransky] (ni? me) (PTO, Back Jun 24)]

(In reply to Tim Nguyen :ntim from comment #8)

(In reply to Ting-Yu Lin [:TYLin] (UTC-8) from comment #7)

Re comment 5:

I know nothing about GTK and window code, but I hack it by replacing

mDraggableRegion.Contains(aEvent->x, aEvent->y)

with

auto p = GetRefPoint(this, aEvent);
mDraggableRegion.Contains(p.x, p.y)

And it fixed the bug for me. GetRefPoint seems to take the DPI into account and is used by serveral places in nsWindow.

On my Double DPI setting, p is twice as large as aEvent->x, y. For example when aEvent->x/y = (309,121.5), p = (618,243). Under normal DPI setting, both are the same.

I wonder if this makes sense?

Thanks for looking into this! The other possible fix I was thinking of was
using event.mRefPoint.x and event.mRefPoint.y (taking the
WidgetMouseEvent coordinate instead of the GdkEventButton coordinates). But
using the GdkEventButton coordinates with GetRefPoint() seems better
here (since WidgetMouseEvent coordinates might be compressed).

Martin, what do you think ?

I think you're right, there's the patch.

Comment 12

[Martin Stránský [:stransky] (ni? me) (PTO, Back Jun 24)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=45c4ec7c63aed272b87bf0b0215c97a9835ec738

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b7d1b3bf0220
[Linux/Gtk] Use GdkEventCoordsToDevicePixels() to get mouse coordinates for mDraggableRegion.Contains(), r=ntim,TYLin

Comment 14

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/b7d1b3bf0220