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.

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

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

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

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 ?

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

(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.

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?

(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 can reproduce it on Wayland/scale factor 2 so it a general issue. I'll look at it.

(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.

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