2014504 - [Wayland] Scrollbar dragging stops for scrollbar of select popup when cursor leaves popup bounds

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Fernando Marcelino Muniz]

Attachment: Video_2026-02-04_14-16-36.mkv

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

Steps to reproduce:

Entered this site
https://bugs.kde.org/enter_bug.cgi?product=plasmashell
Then hold the "Platform:" list's scrollbar, then moved the cursor out of the box.

Actual results:

The scrollbar teleported to the bottom.

Expected results:

It should still be following the cursor's movent as long as I hold the scrollbar.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Scrolling and Overflow' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Timothy Nikkel (:tnikkel)]

I think this might be linux only behaviour? I don't see this on macos.

Comment 3

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

The severity field is not set for this bug.
:hiro, could you have a look please?

For more information, please visit BugBot documentation.

Comment 4

[Botond Ballo [:botond]]

Could you go to about:config and check the value of the pref slider.snapMultiplier?

If it's nonzero, then setting the value to zero (which is the default on Linux) should make the observed behaviour go away.

Comment 5

[Fernando Marcelino Muniz]

It seems it was always set to 0

Comment 6

[Botond Ballo [:botond]]

(In reply to Fernando Marcelino Muniz from comment #5)

It seems it was always set to 0

Thanks for checking. I was mistaken about the issue being related to slider.snapMultiplier.

I can reproduce the issue, on Wayland only (not X11). Scrollbar dragging stops completely when the cursor leaves the bounds of the select popup window, and the scroll position snaps to the bottom, regardless of the position at the start of the drag.

Likely a widget issue but I will check what events APZ is seeing in HandleDragEvent first.

Comment 7

[Botond Ballo [:botond]]

Ok, so what I'm seeing is that on Wayland, as soon as the cursor leaves the bounds of the select popup, the coordinates of the GdkEventMotion events that are passed to motion_notify_event_cb change from being relative to the popup, to being relative to the main browser window.

Here is what an event looks like when the cursor is within the bounds:

{
  type = GDK_MOTION_NOTIFY,
  window = 0x7fcfea5c7e20,
  send_event = 0 '\000',
  time = 404160129,
  x = 182,
  y = 357,
  axes = 0x0,
  state = 256,
  is_hint = 0,
  device = 0x7fd042ccbb30,
  x_root = 844,
  y_root = 886
}

vs. just outside the bounds:

{
  type = GDK_MOTION_NOTIFY,
  window = 0x7fcfea5c7e20,
  send_event = 0 '\000',
  time = 404160265,
  x = 850,
  y = 886,
  axes = 0x0,
  state = 0,
  is_hint = 0,
  device = 0x7fd042ccbb30,
  x_root = 850,
  y_root = 886
}

(182,357) are the correct coordinates relative to the popup, whereas (850,886) are coordinates relative to the main window.

In both cases the window field matches nsWindow::mGdkWindow and so GetRefPoint takes this branch.

On X11, the coordinates remain relative to the popup even when the cursor has left the popup bounds.

Moving to "Widget: Gtk" for further diagnosis.

Comment 8

[Martin Stránský [:stransky] (ni? me)]

WidgetToScreenOffset() is not expensive any more so we may use it.

Comment 9

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 2014504 [Linux] Use WidgetToScreenOffset() and event root coordinates to calc widget coordinates r?emilio

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/bc5077de9ef2
https://hg.mozilla.org/integration/autoland/rev/edca78a74406
[Linux] Use WidgetToScreenOffset() and event root coordinates to calc widget coordinates r=emilio

Comment 11

[amarc]

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