Open Bug 1690313 Opened 2 years ago Updated 1 year ago

Clicking at the very top of the tab item doesn't activate it sometimes

Categories

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

Firefox 85
Unspecified
Linux
defect

Tracking

()

UNCONFIRMED

People

(Reporter: mi2rivtj, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(7 files)

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

Steps to reproduce:

If you click on the very top of the tab item, the click doesn't activate, required subsequent clicks or changing the mouse position.

I attached a video showing the problem.

More details:

Operating System: KDE neon 5.20
KDE Plasma Version: 5.20.5
KDE Frameworks Version: 5.78.0
Qt Version: 5.15.2

Component: Untriaged → Tabbed Browser
OS: Unspecified → Linux

Looks like https://bugzilla.mozilla.org/show_bug.cgi?id=1652446 might be the same issue?

I am experiencing this same bug. Also on KDE Neon;

Operating System: KDE neon 5.20
KDE Plasma Version: 5.20.5
KDE Frameworks Version: 5.78.0
Qt Version: 5.15.2

My system details exactly match yours.

I've successfully reproduced it in Safe Mode and in the Beta and Nightly builds. Open a new window, maximize it, and open a few tabs; click around the top pixel row for a minute or so, eventually the bug will "catch" and you can click on one particular pixel and the tab simply doesn't react. It seems to get worse over time, somehow? It's hard to trigger in a new session, but in a session that's been open for a while, it happens almost half of the time I try clicking on a tab.

Also, it's not just the top row, it's all four edges. Sometimes I'll scroll with the mouse pressed to the left edge of the screen, and the page won't scroll. Maybe that's unrelated; not sure.

Component: Tabbed Browser → Widget: Gtk
Product: Firefox → Core
See Also: → 1652446

I should also add, I've tried it in the Nightly build with the new Proton tab-bar enabled, and the issue still persists.

I tried using xev to monitor the events of the Firefox process but didn't get much of anywhere; too much "noise" when a tab does get successfully clicked. There is an event that goes through on unsuccessful clicks: PropertyNotify event, serial 27, synthetic NO, window 0x3c00e4d, atom 0x1a7 (_NET_WM_USER_TIME), time 48786213, state PropertyNewValue. I don't know enough about X to really interpret this in any way.

Here's the video with a mouse click effect.

It seems to happen more when that are lots of tabs opened.

You can use Browser Toolkit to investigate how big is the button active area, see https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox

Priority: -- → P3

You can use Browser Toolkit to investigate how big is the button active area, see

I'm not familiar with this tool D: How do I start after activating it? Also, the "remote" part is actually localhost-only, right?

(In reply to mi2rivtj from comment #9)

You can use Browser Toolkit to investigate how big is the button active area, see

I'm not familiar with this tool D: How do I start after activating it? Also, the "remote" part is actually localhost-only, right?

Remote means you can debug your running Firefox instance from another Firefox process so you can inspect Firefox UI.

Attached video remote debugging

Nothing seems to be wrong. Also, I asked in Reddit if GNOME users were having this issue and nobody was facing this (I'm using KDE by the way).

I think I found a clue: it seems that the KDE tooltip might be interfering in the click action, but I'm not sure.

I have same issue (also using kde), it turns out that is due to environment variable MOZ_USE_XINPUT2=1.
If I set it to 0 it is working fine.

I found out that this is related to smooth scrolling. Where can I disable this variable?

Nevermind, I found it! echo export MOZ_USE_XINPUT2=1 | sudo tee /etc/profile.d/use-xinput2.sh Is there any downsides when changing this?

I was able to record the moment of the bug happening (I don't know why, but it feels like the tooltip is also causing this).

(In reply to mi2rivtj from comment #15)

Nevermind, I found it! echo export MOZ_USE_XINPUT2=1 | sudo tee /etc/profile.d/use-xinput2.sh Is there any downsides when changing this?

https://wiki.archlinux.org/title/Firefox#Touchscreen_gestures_and_pixel-perfect_trackpad_scrolling
Scrolling is much better when using trackpad.

I also tested this on gnome with dash to panel extension, same issue occures with MOZ_USE_XINPUT2=1.

Hovever if I switch to wayland on both gnome and kde it is always working fine.

I'm using Kubuntu 21.04 and this isn't happening. KDE Neon is based on Ubuntu 20.04 by the way.

Attached video 2021-06-14 12-17-17.mkv

(In reply to mi2rivtj from comment #19)

I'm using Kubuntu 21.04 and this isn't happening. KDE Neon is based on Ubuntu 20.04 by the way.

Huh that's strange, I also tested it on Kubuntu 21.04 an same bug occures.
Here's a video: https://bugzilla.mozilla.org/attachment.cgi?id=9226794

I'm using Firefox opening it through the Application Launcher. The shortcut of Firefox doesn't have this variable by default (it's just "firefox %u").

Hi, using firefox on opensuse-tumbleweed with xfce4 I'm also having this bug. I noticed that unsetting MOZ_USE_XINPUT2 solves issue on my end. I used to run firefox binary from extracted packages from Mozilla website, later on I switched to my distro's firefox and found out firefox points to an shell script file setting this variable.

You need to log in before you can comment on or make changes to this bug.