Closed Bug 1752162 Opened 8 months ago Closed 6 months ago

Downward autoscrolling while selecting text doesn't work on wayland

Categories

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

Firefox 96
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: iamtrazy, Unassigned)

References

(Blocks 1 open bug)

Details

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

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

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.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core

Really odd, happens also with the mouse too.

Blocks: wayland
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Downward autoscrolling while selecting from touchpad doesn't work on wayland → Downward autoscrolling while selecting text doesn't work on wayland

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

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

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.

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

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

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?

Flags: needinfo?(robert.mader)
Depends on: 1752214

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

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.

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

Flags: needinfo?(robert.mader)

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

Priority: -- → P3

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

Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.