1752162 - Downward autoscrolling while selecting text doesn't work on wayland

Status: RESOLVED WORKSFORME

(Core :: Widget: Gtk, defect, P3)

Description

[iamtrazy]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:96.0) Gecko/20100101 Firefox/96.0

Steps to reproduce:

selecting text using touchpad with double tap and dragging down on a webpage

Actual results:

only able to select the text currently displayed on the page , did not auto scroll downwards to select the text below the currently displayed section . but if i go upward direction page auto scrolls and selected everything above

Expected results:

should auto scroll downwards when the cursor moved to the end of the current section . works fine on x11 and xwayland

Comment 1

[iamtrazy]

if i open find in page or unmaximize the firefox window downward scroll works.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Really odd, happens also with the mouse too.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Doesn't seem like a recent regression (happens in a build from 2020-10-20 at least)

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Can you confirm that it also works as expected in full-screen (F11)?

Comment 6

[Emilio Cobos Álvarez (:emilio)]

This is because this code is not working correctly on Wayland. Presumably, GetScreenRect is off by a bit compared to the actual screen rect? Probably because WidgetToScreenOffset is off, because the on Wayland we don't have absolute window positions.

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Right, so, on a maximized window, on the browser console, run:

• windowUtils.toScreenRectInCSSUnits(0, 0, 0, 0)

On X11 that returns an y coordinate that matches the GNOME top bar, but on Wayland it returns 0. Since that disagrees with screen.height, we think we still have some leeway to move the mouse down, which we don't...

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Curiously, when the window is not maximized, we return x=45, y=45, which is rather odd?

Comment 9

[Emilio Cobos Álvarez (:emilio)]

So, anyways, this is because we use the wl_output to compute screen size, but then WidgetToScreenOffset isn't aware of the real window position, so our screen coordinates are basically off by the top bar in the GNOME desktop.

Presumably there's no way to know the position of our top-level wl_surface relative to the wl_output?

Comment 10

[Emilio Cobos Álvarez (:emilio)]

The 45px here come from https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gtk/gtkwindow.c#L7609 fwiw.

Comment 11

[iamtrazy]

I can confirm that this problem doesn't appear on fullscreen mode. also im on gnome wayland , idont know if this is a bug related to mutter

Comment 12

[lilydjwg]

wayfire here, a wlroots-based compositor.

• it scrolls down in fullscreen, or if my mouse goes outside the window
• it scrolls up when my mouse goes up, on this page into the black bar
• when maximized and my mouse reaches the bottom of screen, it doesn't scroll down. Instead, the selection becomes from page start to where I started the selection.
• if I put my desktop's bar (panel) at the bottom, it scrolls down when my mouse reaches there

In case the mouse is outside, the selection becomes from page start to where I started the selection until I move my mouse into firefox's window again.

Comment 13

[Robert Mader [:rmader]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #9)

Presumably there's no way to know the position of our top-level wl_surface relative to the wl_output?

Indeed there isn't. Thanks for making bug 1752214!

Comment 14

[Hugo Osvaldo Barrera]

Works for me on fullscreen windows as well as non-fullscreen windows on sway 1.7 and firefox 96.0.2.

Comment 15

[iamtrazy]

i can now confirm that bug is fully fixed on firefox nightly 98.0a1