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

Status: UNCONFIRMED

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

Description

[mi2rivtj]

Attachment: simplescreenrecorder-2021-02-02_13.31.55.mp4

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.

Comment 1

[mi2rivtj]

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

Comment 2

[John]

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

Comment 3

[Nikola]

Attachment: about:support text view

Comment 4

[Nikola]

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.

Comment 5

[Nikola]

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.

Comment 6

[mi2rivtj]

Attachment: simplescreenrecorder-2021-05-25_00.26.39.mp4

Here's the video with a mouse click effect.

Comment 7

[mi2rivtj]

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

Comment 8

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

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

Comment 9

[mi2rivtj]

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?

Comment 10

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

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

Comment 11

[mi2rivtj]

Attachment: 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).

Comment 12

[mi2rivtj]

Attachment: Screenshot_20210602_195413.png

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

Comment 13

[gobonja]

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.

Comment 14

[mi2rivtj]

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

Comment 15

[mi2rivtj]

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?

Comment 16

[mi2rivtj]

Attachment: tooltip might be causing 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).

Comment 17

[gobonja]

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

Comment 18

[gobonja]

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.

Comment 19

[mi2rivtj]

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

Comment 20

[gobonja]

Attachment: 2021-06-14 12-17-17.mkv

Comment 21

[gobonja]

(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

Comment 22

[mi2rivtj]

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

Comment 23

[unsalcan35]

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.