Closed Bug 1660212 Opened 4 years ago Closed 4 years ago

Some clicks ignored on topmost pixel row using XInput2

Categories

(Core :: Widget: Gtk, defect)

Product:
Core
Component:
Widget: Gtk
Version:
Firefox 81
Platform:
Unspecified
Linux
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
82 Branch
Tracking Flags:
Tracking Status
firefox81 --- fixed
firefox82 --- fixed

People

(Reporter: ElementW, Assigned: stransky)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

Bug 1660212 Disable XINPUT2 by default (revert Bug 1207700), r?botond
47 bytes, text/x-phabricator-request
RyanVM
: approval-mozilla-beta+
Details | Review

Repro steps: Run Firefox with MOZ_USE_XINPUT2=1, and optionally maximize the window without Window Manager frame borders so that the topmost pixel row of Firefox's content aligns with the topmost pixel the mouse pointer can go.
Open several tabs and try switching between them with the cursor at its topmost position on the vertical axis.

Expected: All clicks should be properly handled; tabs should switch when left clicked, close when middle clicked, and open context menu when right clicked.

Actual: At least 20% of the clicks are lost/ignored if moving the mouse randomly horizontally. It is possible to find positions where clicks never go through. This includes all types of clicks (left, middle, right).

Happens on both 2020-08-19 nightly and 79.0 stable. Doesn't happen when XInput2 isn't used.
Tested on x86_64 Linux w/ Xorg 1.20.8, xorg-xinput 1.6.3, xf86-input-libinput 0.30.0, libinput 1.15.6

Botond, can you take a look? Is it possible this is related to https://bugzilla.mozilla.org/show_bug.cgi?id=1207700?

Flags: needinfo?(botond)

It does look like an issue with XInput2. Moving to Widget: Gtk and cc'ing Martin and Karl. (The relation to bug 1207700 is just that we made XInput2 the default (for new enough GTK versions) in that bug.)

Blocks: 1207700
Component: General → Widget: Gtk
Flags: needinfo?(botond)
Product: Firefox → Core

I have this issue with the right-most pixel column in a fullscreen window. Both hovers and clicks are sometimes not registered. This is especially noticeable when I hover over the gtk scrollbar and it doesn't always highlight.
This happens since bug 1207700 landed.

I reported this extremely annoying bug to KDE because I thought it was related to something in NEON. You can find more info here:
https://bugs.kde.org/show_bug.cgi?id=424914

I have similar reports from gnome users so it's not KDE only bug. I'm afraid the input issues are fixed on Wayland only and X11 will stay broken forever. Let's revert Bug 1207700 until it hits more users.

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

I have similar reports from gnome users so it's not KDE only bug. I'm afraid the input issues are fixed on Wayland only and X11 will stay broken forever. Let's revert Bug 1207700 until it hits more users.

That's unfortunate, but I agree that reverting bug 1207700 altogether is probably the right call in this case. Please go ahead and post a revert patch (which we can then uplift to 81 as well).

Can we keep this behavior on Wayland at least?

(In reply to Nate Graham from comment #7)

Can we keep this behavior on Wayland at least?

Yep, touch-scrolling already worked with Wayland prior to bug 1207700, and will continue working after the revert.

Is far as I can tell, the issue with the top-most row of pixels shouldn't affect Gnome as it has it's own top bar. Can we at least keep XInput2 enabled specifically for Gnome users?

Also, maybe I'm missing something, but is there any reason the actually bug can't be fixed in FF's XInput2 code rather than just disabling the backend? Obviously disabling is a good stop-gap, but maybe only disable XInput2 for the Release channel so there's still pressure to fix the root issue (if possible) and eventually get XInput2 out to all users?

(In reply to QwertyChouskie from comment #9)

Is far as I can tell, the issue with the top-most row of pixels shouldn't affect Gnome as it has it's own top bar. Can we at least keep XInput2 enabled specifically for Gnome users?

Martin mentioned getting reports about the same issue from Gnome users (comment 5). Perhaps it's from configurations where the top bar is hidden or moved to the bottom.

Note also, the issue seems to affect not just the topmost row of pixels, but also the rightmost row, which can affect scrollbars (comment 3).

Also, maybe I'm missing something, but is there any reason the actually bug can't be fixed in FF's XInput2 code rather than just disabling the backend?

At this point, it's unclear if the issue is with XInput2 itself, or Firefox's usage of it. Someone familiar with X/GDK/GTK would need to investigate and find out, and if it is a Firefox issue, come up with a fix.

If anyone is up for investigating this, that would be greatly appreciated.

Obviously disabling is a good stop-gap, but maybe only disable XInput2 for the Release channel so there's still pressure to fix the root issue (if possible) and eventually get XInput2 out to all users?

It's not clear that telling one group of Nightly / Beta users to use MOZ_USE_XINPUT2=0 to get the topmost/rightmost pixels responsive again would be an improvement over telling another group of Nightly / Beta users to use MOZ_USE_XINPUT2=1 to get touch scrolling. The latter has been the status quo for a while, it's probably less disruptive to keep it that way.

I don't really understand how any of this works, but all I can say is that it doesn't seem to happen on Linux Mint for me, only on Neon. Is there any workaround for this issue? I don't mind installing beta versions or anything as long as I can click on the top of tabs like I usually do without getting exponentially more angry at each missed click.

Also how the heck is it possible that there isn't an uproar over this, what kind of weirdo doesn't use Firefox without the menu bar in fullscreen all the time?

(In reply to pixtran from comment #11)

I don't really understand how any of this works, but all I can say is that it doesn't seem to happen on Linux Mint for me, only on Neon. Is there any workaround for this issue? I don't mind installing beta versions or anything as long as I can click on the top of tabs like I usually do without getting exponentially more angry at each missed click.

Also how the heck is it possible that there isn't an uproar over this, what kind of weirdo doesn't use Firefox without the menu bar in fullscreen all the time?

And let me add that this bug appears to be over a month old and firefox is nearly unusable in this pathetic, click-missing state of affairs. But nobody seems to have noticed it other than myself and a few others, so maybe I'm the weird and everyone else uses Firefox in some other way and not maximized, or with a huge useless title bar on top that serves no actual purpose in the current year.

(In reply to pixtran from comment #11)

I don't really understand how any of this works, but all I can say is that it doesn't seem to happen on Linux Mint for me, only on Neon.

I don't think we have a good sense for what specifically causes this, other than "somehow a side effect of enabling XInput2".

For what it's worth, I use KDE (though an older version than Neon), and I don't see this. Granted, I do have a title bar, but clicking on the top row of pixels on the title bar works fine for me (to e.g. activate the window if it's not active already, or to start dragging it if it is). I also tried disabling the title bar, and in that case clicking on the top row of pixels works fine to switch tabs. Clicking the rightmost pixels to start dragging the scrollbar works fine, too.

My point here is that even for KDE, some users (or perhaps some KDE versions) are affected and others are not.

Is there any workaround for this issue?

Disabling XInput2 by running Firefox with MOZ_USE_XINPUT2=0 in the environment should work around this issue.

As mentioned in comment 6, we are going to revert the default-enablement of XInput2 so the issue will be fixed without the need for this workaround soon.

Also how the heck is it possible that there isn't an uproar over this, what kind of weirdo doesn't use Firefox without the menu bar in fullscreen all the time?

First, the regression only affects Firefox 81 and later. These are currently the Nightly and Beta channels. Release is not currently affected, so the pool of affected users is smaller.

Second, if I understand correctly, the issue only affects one row of pixels. The tab bar is something like 10-20 pixels in height. If you click on any row of pixels other than the very top, it works fine.

Third, at least for official builds, the title bar is shown in the default configuration, you have to go into Customize to hide it. My guess is not many users do that, thereby further decreasing the population of users affected by this. (I'm not sure what distro builds do here. Maybe they hide the title bar by default, in which case please ignore this point.)

My guess for why people aren't more upset:

  1. In Plasma distros, typically the SSD titlebar is turned on by default because it better matches the UX of the rest of the platform, so the problem isn't seen at all.
  2. On GNOME, the top bar prevents anyone from noticing that the top-most pixel eats clicks when the CSD headerbar mode is in use.
  3. This change was made very recently.

So the people who notice it are bleeding edge Plasma users who have enabled the CSD headerbar, or bleeding edge GNOME users who have hidden or relocated the default top bar. I guess it's not a lot of people. Personally I use and prefer the standard SSD titlebar on Plasma so I didn't encounter this problem.

First, the regression only affects Firefox 81 and later.

Nope. Like I said in the KDE bugtracker, it happens also on older Firefox, for example, to me it happens on an old version of GNU Icecat that I had lying around (60.7.0esr (64-bit)). That's why at first I thought it was related to KDE because this Icecat was never updated (or used more than a couple of times to try it out a long time ago).

Disabling XInput2 by running Firefox with MOZ_USE_XINPUT2=0 in the environment should work around this issue.

I added the env variable but nothing changes for me.

Some more info I can give you:
the same things happen also on the live ISO of KDE Neon.
The leftmost column of pixels is also unresponsive like other users said.

I'm really thankful that you're looking into it.

(In reply to pixtran from comment #15)

First, the regression only affects Firefox 81 and later.

Nope. Like I said in the KDE bugtracker, it happens also on older Firefox, for example, to me it happens on an old version of GNU Icecat that I had lying around (60.7.0esr (64-bit)). That's why at first I thought it was related to KDE because this Icecat was never updated (or used more than a couple of times to try it out a long time ago).

Disabling XInput2 by running Firefox with MOZ_USE_XINPUT2=0 in the environment should work around this issue.

I added the env variable but nothing changes for me.

Some more info I can give you:
the same things happen also on the live ISO of KDE Neon.
The leftmost column of pixels is also unresponsive like other users said.

If you're experiencing this even with XInput2 disabled, you may be running into a different underlying bug causing the same symptoms. Could you file a new bug report for it please? Feel free to mention the bug number in a comment on this bug.

The environment I used for the bug report is XFCE, with xfwm4 4.14.5 with the "Hide title of windows when maximized" option, aka xfwm4/borderless_maximize xfconf entry, so it sure looks like the bug isn't DE/WM-specific.
Also tested with KDE kwin_x11 5.19.5 with BorderlessMaximizedWindows=true in kwinrc, which isn't "bleeing edge" as Nate said although I believe is rarely enabled due to lacking a checkbox in system settings.

Assignee: nobody → stransky
Pushed by ccoroiu@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/4ee2a5b88101 Disable XINPUT2 by default (revert Bug 1207700), r=botond

Comment on attachment 9175458 [details]
Bug 1660212 Disable XINPUT2 by default (revert Bug 1207700), r?botond

Beta/Release Uplift Approval Request

  • User impact if declined: Various mouse input regression on KDE/Gnome.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): It reverts Bug 1661219 and uses the XINPUT2 state we have in Firefox 80 so there's no change in Firefox 81 if the patch is applied.
  • String changes made/needed:
Attachment #9175458 - Flags: approval-mozilla-beta?

Comment on attachment 9175458 [details]
Bug 1660212 Disable XINPUT2 by default (revert Bug 1207700), r?botond

Approved for 81.0rc1.

Attachment #9175458 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

https://hg.mozilla.org/mozilla-central/rev/4ee2a5b88101

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
status-firefox82: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 82 Branch

Hello Firefox geniuses. Correct me if I'm wrong, but shouldn't it be fixed on FF82?
Because I just updated on my system (Firefox Version is now 82.0b2) and I still have the issue. Top row of pixels (tabs) and left side are still unresponsive 90% of the time.

Yes, this should be fixed. Is the MOZ_USE_XINPUT2 set by some mistake for instance?
If not, can you try to use mozregression to find a culprit?

Flags: needinfo?(pixtran)

Yes, the variable was being set by a script.
I'm honestly not sure if I made this one or if it was set this way by the OS
/etc/xdg/plasma-workspace/env/neon_moz_use_xinput.sh
This script set the variable.
I'm pretty sure I didn't create this.

Oh well, it's fixed now. Thank you very much.

Flags: needinfo?(pixtran)
No longer blocks: 1207700
Keywords: regression
Regressed by: 1207700
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: