1565313 - [Wayland] Clicking within the autoscroll widget causes cursor to not work.

Status: UNCONFIRMED

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

Description

[rpigott]

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

Steps to reproduce:

With recent bugfixes, I've started using the Wayland backend for firefox and I've noticed a strange behavior with autoscroll:

On X11, I can use middle click anywhere to engage and click anywhere to disengage.
On Wayland, the behavior is the same, but if you click to disengage within the autoscroll widget, cursor events (like hover and click) have no effect.

You can try it here on the bugzilla:

1. Set MOZ_ENABLE_WAYLAND=1
2. Enable general.autoScroll in preferences or about:config
3. Middle click anywhere to engage autoscroll if the page has y-scroll
4. Left click within the autoscroll widget, does not matter if you actually have scrolled the page anywhere or not.
5. Hover / click over a link
6. Click again anywhere in the Firefox window to reset to normal.

So in practice sometimes one additional click is required to completely disengage autoscroll

I've get this behavior with every combination of these archlinux packages:
(sway 1.1.1-3 / weston 6.0.1-1) + (firefox 68.0-1 / firefox-nightly 70.0a1.20190710-1)

behavior is fine through XWayland.

To be clear, the Firefox window has not lost focus, and keyboard events still work fine, but the cursor behavior is not restored until you click.

Actual results:

When following the above steps, the hover will not transform the cursor to a hand, and clicking will not follow the link. Clicking one additional time will work normally.

Expected results:

Clicking within the autoscroll widget should disengage autoscroll the same as clicking outside the autoscroll widget on wayland just like on X11.

Comment 1

[Angus]

Can confirm with FF 68.0.1 under GNOME 3.32.2 on Arch with Intel graphics. Additionally, when middle-clicking FF under XWayland will display a circular/NSEW autoscroll marker on the page correctly, but under Wayland this marker is invisible.

Comment 2

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

IIUC the problem is that click inside the autoscroll widget does not chancel the autoscroll on Wayland but does chancel it on X11, correct? And click outside the widget chancels autoscroll on both X11 and Wayland correctly. Am I correct?

Comment 3

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

(In reply to Angus from comment #1)

Can confirm with FF 68.0.1 under GNOME 3.32.2 on Arch with Intel graphics. Additionally, when middle-clicking FF under XWayland will display a circular/NSEW autoscroll marker on the page correctly, but under Wayland this marker is invisible.

I don't see this issue, at least on Fedora 30 / gnome-shell-3.32.2-2.fc30.x86_64 / latest nightly.

Comment 4

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

Actual results:

When following the above steps, the hover will not transform the cursor to a hand, and clicking will not follow the link. Clicking one additional time will work normally.

Ahh, I see this on Firefox 68 but not on latest nightly. Firefox 68 chancels the autoscroll widget when it's clicked in but the mouse cursor remains non-functional until it's clicked again somewhere.

Comment 5

[rpigott]

I actually still observe the buggy behavior in firefox-nightly 70.0a1.20190725-1 on both sway 1.1.1 and weston 6.0.1.

Comment 6

[rpigott]

I just installed gnome-shell and I actually still observe the buggy behavior in firefox-nightly 70.0a1.20190725-1 on my arch system with gnome-shell 1:3.32.2+6+g8b9874089-1 / mutter 3.32.2+40+gccab0f470-2. I started gnome-shell with "XDG_SESSION_TYPE=wayland MOZ_ENABLE_WAYLAND=1 dbus-run-session gnome-shell"

Maybe its caused by another factor? Maybe its triggered by something? My strategy so far has been to start each wayland compositor on another tty and switch between them to compare.

I have webrender enabled by pref on my FF68 but I observe the buggy behavior with and without webrender. I did not modify any prefs on firefox-nightly but it seems webrender is enabled.

In case it helps,
my graphics hardware:

$ lspci -kvnn | sed -n '/VGA/,/^$/ p'
00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 630 [8086:591b] (rev 04) (prog-if 00 [VGA controller])
	DeviceName:  Onboard IGD
	Subsystem: Dell HD Graphics 630 [1028:07be]
	Flags: bus master, fast devsel, latency 0, IRQ 142
	Memory at eb000000 (64-bit, non-prefetchable) [size=16M]
	Memory at 80000000 (64-bit, prefetchable) [size=256M]
	I/O ports at f000 [size=64]
	[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
	Capabilities: [40] Vendor Specific Information: Len=0c <?>
	Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
	Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit-
	Capabilities: [d0] Power Management version 2
	Capabilities: [100] Process Address Space ID (PASID)
	Capabilities: [200] Address Translation Service (ATS)
	Capabilities: [300] Page Request Interface (PRI)
	Kernel driver in use: i915
	Kernel modules: i915

Comment 7

[rpigott]

I've done some further testing and found some details:

The actual area where one can click to cause the bug does not coincide exactly with the widget, instead it is the square area within which the cursor can move before triggering scrolling when starting autoscroll, irrespective of whether or not the page has scrolled. Basically its a small square area surrounding the widget.

Additionally, on sway (and probably other compositors), starting autoscroll then using keyboard shortcuts to remove focus from the Firefox window while the cursor is in the affected area cancels autoscroll and does not cause the bug -- mouse events are restored normally.

I took a quick look and perhaps the behavior has something to do with the mouse event logic here?
https://hg.mozilla.org/mozilla-central/file/f30055b91e96481970506158162b5a44e93f9934/toolkit/content/widgets/browser-custom-element.js#l1782
I wouldn't know how to begin debugging though...

Comment 8

[rpigott]

I can no longer reproduce as described in firefox-nightly 71.0a1.20190904 on sway 1.2.

In FF71 the behavior has changed, and now it is impossible to dismiss the widget by clicking in the affected area. Clicking outside the widget functions properly, as it did before, to dismiss the widget. I think the new behavior is preferable to the old, but it would still be nice to be able to dismiss the scroll widget by clicking within its bounding box as is possible on X11.

Comment 9

[Angus]

(In reply to Martin Stránský [:stransky] from comment #3)

(In reply to Angus from comment #1)

Can confirm with FF 68.0.1 under GNOME 3.32.2 on Arch with Intel graphics. Additionally, when middle-clicking FF under XWayland will display a circular/NSEW autoscroll marker on the page correctly, but under Wayland this marker is invisible.

I don't see this issue, at least on Fedora 30 / gnome-shell-3.32.2-2.fc30.x86_64 / latest nightly.

Can confirm the missing marker is no longer an issue. It was a problem when running with GDK_BACKEND=wayland but works when running with MOZ_ENABLE_WAYLAND=1 instead. Please ignore.

However, the main bug report of this thread is still present with release FF 70.0.1 under Gnome 3.34.1. I agree with rpigott's comment above about ideally mimicking X11/other OS behaviour as the best resolution.