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

Steps to reproduce:

Private window, twitch, click on menu over video for streamers with CC enabled (this also happens on sites with ... menus that pop up like mattermost)

Actual results:

Mouse click doesn't register

Expected results:

Menu intractable.

To elaborate - sometimes the clicks don't register, some times it gets sent behind pop-up menus and you will double click and highlight things on a page, other things it will just make the menu disappear.

And I noticed this on the 8th of Dec 2022 if anyone wants to bisect

uhhh ok even more weird-er-ist

In normal browsing I have vimium disabled for twitch. But clicking on the popup menu apparently goes to ext-twitch.tv which is not disabled for vimium. And enables vimium. Not sure if that's related to the clicking behavior.

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

Looks like this got fixed last night or today? I'll leave it open just in case. But feel free to close if I forget about it.

As soon as I sent that it quit working...

Thanks for the report! Please open about:support, click on "Copy text to clipboard" and paste it here.
Do you have ArchLinux or OpenSUSE Tumbleweed (bug 1801820)?

Please try to find a regression range:
$ pip3 install --upgrade mozregression
$ ~/.local/bin/mozregression --good 2022-12-01 --bad 2022-12-15 -a https://twitch.tv

on void, haven't seen that freezing at all and i've been using libx11 1.8.2 for a monthish now. fwiw, i'm on latest of a bunch of crap for intel a770 gpu and im kind of thinking kernel 6.0+ may have some futex issue going on with locks.

the bug is 100% reproducible so if i get time ill try a bisect.

(In reply to zlice from comment #8)

on void, haven't seen that freezing at all and i've been using libx11 1.8.2 for a monthish now. fwiw, i'm on latest of a bunch of crap for intel a770 gpu and im kind of thinking kernel 6.0+ may have some futex issue going on with locks.

the bug is 100% reproducible so if i get time ill try a bisect.

The libx11 1.8.2 bug is a futex problem (bug 1805159=bug 1801820=https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/168).
Please check if downgrading to libx11 1.8.1 avoids the problem.

libx11 1.8.1 does not appear to solve the issue

what auto bisect says is bad

 5:26.10 INFO: Using local file: /tmp/tmp8d71gdfy/29d3931389be-pgo--autoland--target.tar.bz2 (downloaded in background)
 5:26.10 INFO: Running autoland build built on 2022-12-08 14:11:29.544000, revision 29d39313
 5:33.01 INFO: Launching /tmp/tmp7qmxw8ei/firefox/firefox
 5:33.01 INFO: Application command: /tmp/tmp7qmxw8ei/firefox/firefox https://www.twitch.tv/unclelander -profile /tmp/tmp4nnp4d4_.mozrunner
 5:33.02 INFO: application_buildid: 20221206204422
 5:33.02 INFO: application_changeset: 29d3931389bec793e99c9174a61f4c663660d4fd
 5:33.02 INFO: application_name: Firefox
 5:33.02 INFO: application_repository: https://hg.mozilla.org/integration/autoland
 5:33.02 INFO: application_version: 109.0a1
Was this integration build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', 'back' or 'exit' and press Enter): good
 5:40.84 INFO: Narrowed integration regression window from [00327070, 42315c02] (3 builds) to [29d39313, 42315c02] (2 builds) (~1 steps left)
 5:40.84 INFO: No more integration revisions, bisection finished.
 5:40.84 INFO: Last good revision: 29d3931389bec793e99c9174a61f4c663660d4fd
 5:40.84 INFO: First bad revision: 42315c0234717f5f17913b750a2559ee1c6683c7
 5:40.84 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=29d3931389bec793e99c9174a61f4c663660d4fd&tochange=42315c0234717f5f17913b750a2559ee1c6683c7

idk if this means anything but this worked for a couple clicks toggling a ui then crashed

 3:54.24 INFO: Running autoland build built on 2022-12-06 22:11:49, revision 42315c02
 4:01.14 INFO: Launching /tmp/tmpy47uwbw4/firefox/firefox
 4:01.14 INFO: Application command: /tmp/tmpy47uwbw4/firefox/firefox https://www.twitch.tv/unclelander -profile /tmp/tmptkmqqeh7.mozrunner
 4:01.15 INFO: application_buildid: 20221206204650
 4:01.15 INFO: application_changeset: 42315c0234717f5f17913b750a2559ee1c6683c7
 4:01.15 INFO: application_name: Firefox
 4:01.15 INFO: application_repository: https://hg.mozilla.org/integration/autoland
 4:01.15 INFO: application_version: 109.0a1
Was this integration build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', 'back' or 'exit' and press Enter): 
 4:07.81 WARNING: Process exited with code 11

(In reply to zlice from comment #11)

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=29d3931389bec793e99c9174a61f4c663660d4fd&tochange=42315c0234717f5f17913b750a2559ee1c6683c7

42315c0234717f5f17913b750a2559ee1c6683c7 Nika Layzell — Bug 1799222 - Prevent accidental dispatches to threadpool and timer threads, r=xpcom-reviewers,necko-reviewers,geckoview-reviewers,media-playback-reviewers,jesup,m_kato,padenot,kmag

Thanks!
That commit has been reverted (backed out) by de29cd51a2e1d36e6e08307d078385050d38e711 for causing failures.
Please run mozregression again (to check if de29cd51a2e1d36e6e08307d078385050d38e711 has been fine and if relanding bug 1799222 or a different patch caused the problem for you):

$ ~/.local/bin/mozregression --repo autoland --good de29cd51a2e1d36e6e08307d078385050d38e711 --bad 2022-12-19 -a https://twitch.tv

(In reply to zlice from comment #8)

Crash Reports for the Last 3 Days
Report ID: bp-d6c7578a-bc4c-47bf-85b7-f10e00221218

That crash might be bug 1779558 and be fixed by upcoming https://cgit.freedesktop.org/drm-tip/commit/?id=801fa7a81f6da533cc5442fc40e32c72b76cd42a.

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e0eac08ef8bc57af069cebff1aaf72080ea3c024&tochange=9b1c242dc2e0dce955e83320a28227c9817d9d57

pointer grabs? that has to be it

 2:55.63 INFO: Using local file: /tmp/tmp5dr54f14/9b1c242dc2e0-shippable--autoland--target.tar.bz2 (downloaded in background)
 2:55.63 INFO: Running autoland build built on 2022-12-08 13:58:04.375000, revision 9b1c242d
 3:02.53 INFO: Launching /tmp/tmpfakk3ec3/firefox/firefox
 3:02.53 INFO: Application command: /tmp/tmpfakk3ec3/firefox/firefox https://www.twitch.tv/kmrkle -profile /tmp/tmp56hubdad.mozrunner
 3:02.53 INFO: application_buildid: 20221206225723
 3:02.53 INFO: application_changeset: 9b1c242dc2e0dce955e83320a28227c9817d9d57
 3:02.53 INFO: application_name: Firefox
 3:02.53 INFO: application_repository: https://hg.mozilla.org/integration/autoland
 3:02.53 INFO: application_version: 109.0a1
Was this integration build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', 'back' or 'exit' and press Enter): bad
 3:09.60 INFO: Narrowed integration regression window from [e0eac08e, 66795b02] (4 builds) to [e0eac08e, 9b1c242d] (3 builds) (~1 steps left)
 3:09.60 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e0eac08ef8bc57af069cebff1aaf72080ea3c024&tochange=9b1c242dc2e0dce955e83320a28227c9817d9d57

 3:09.60 INFO: Using local file: /tmp/tmp5dr54f14/850c9756f206-shippable--autoland--target.tar.bz2 (downloaded in background)
 3:09.60 INFO: Running autoland build built on 2022-12-08 13:52:38.981000, revision 850c9756
 3:16.48 INFO: Launching /tmp/tmp8vshjo6z/firefox/firefox
 3:16.48 INFO: Application command: /tmp/tmp8vshjo6z/firefox/firefox https://www.twitch.tv/kmrkle -profile /tmp/tmpask_o2mj.mozrunner
 3:16.48 INFO: application_buildid: 20221206223244
 3:16.48 INFO: application_changeset: 850c9756f206a4e29a7b2720fad6c918ffda33df
 3:16.48 INFO: application_name: Firefox
 3:16.48 INFO: application_repository: https://hg.mozilla.org/integration/autoland
 3:16.48 INFO: application_version: 109.0a1
Was this integration build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', 'back' or 'exit' and press Enter): good
 3:23.99 INFO: Narrowed integration regression window from [e0eac08e, 9b1c242d] (3 builds) to [850c9756, 9b1c242d] (2 builds) (~1 steps left)
 3:23.99 INFO: No more integration revisions, bisection finished.
 3:23.99 INFO: Last good revision: 850c9756f206a4e29a7b2720fad6c918ffda33df
 3:23.99 INFO: First bad revision: 9b1c242dc2e0dce955e83320a28227c9817d9d57
 3:23.99 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=850c9756f206a4e29a7b2720fad6c918ffda33df&tochange=9b1c242dc2e0dce955e83320a28227c9817d9d57

I'm confused about what the steps to repro this are (sorry, might be me being slow), can you post a screencast? Which menu do I need to click on? Presumably this is related to context menus? Also, what desktop environment are you using? about:support doesn't say. I've tried plasma and gnome on X11 and I don't see anything weird or broken.

No, I wasn't clear because I really don't know what these are.

So the highlight middle menus (and I think the ones above on the right) will click-through and act like a double-click, highlighting the page, or otherwise clicking 'behind' whatever is there.

The bottom right behaves normally.

On other sites I've seen in-site menus for things url copies or reacts do the same thing.

Hope that make sense?

And to make it fun, not everyone had widgets like that on twitch (and even more fun, 30sec ad rolls). Twitch and Mattermost are the main places I've seen this.

fluxbox

fml...it's a fluxbox issue...another bug ill fix and not commit

(In reply to zlice from comment #18)

fml...it's a fluxbox issue...another bug ill fix and not commit

Does this mean we can close this bug as INVALID?
(Fluxbox seems to be an old project on sourceforge that is dead since 2015.)

it's in git -.- but ya it's pretty dead

*sigh* ya, close. idk the FF code enough, or what may be wrong in fluxbox, to say for sure but it's probably fluxbox side (xdotool with the mouse over that 'cc' button just worked).

Yeah, I'd be surprised if my patch caused this on the Firefox side since we're making the X11 server do less work.

So I was in the middle of debugging this, going crazy, because even the simplest of window managers that work have just a XAllowEvents+ReplayPointer and I got down to just that. But I noticed on a Firefox reboot that tab titles were bolded. And one of these menus started working again... In Mattermost you can open a thread and the same ... menu that doesn't work in the main window works in the thread window. I guess I can say I fixed more slop with Fluxbox but I'm absolutely bewildered at what would cause this...If anyone thinks it may get fixed or has any direction, thanks.

I know this is closed but I just wanted to update for record keeping sake. Apparently the 1 ... menu that works is only the first message in a thread. The rest behave like the original issue and click-through.

So I've been messing around far too much the last couple days and here's what I've found.

Putting a small usleep(15000) (15-20 seems to be the sweet spot?) before XAllowEvents+ReplayPointer can allow a click spam to activate ... menus after a few clicks.

Seeing the EnsureGrabs and RetryGrab code makes me think this may be on the Firefox side, as everything else seems to work as expected (normal clicks and highlights in FF, as well as other programs)

I ran into what I think is the same issue, with fvwm2; so far I've seen it with Duolingo and Slack. The general form of affected content is: there's an element E1 where mousing over it causes element E2 to appear, and E2 will disappear if the pointer isn't in E1 or E2. The bug is that a mouse-down seems to cause a spurious mouse-leave; if the pointer is in E2 but not E1, then E2 disappears and an element that was behind it can be clicked on instead, but if the pointer was still in E1, then the popover doesn't visibly change and the click just isn't registered. Concretely: on Duolingo, the elements in the menu bar at the top are E1 and the corresponding menus are E2; menu items can't be clicked on and it's possible to accidentally click on an element that was behind the menu. On Slack, each message is E1 and the buttons at the top right (e.g., for emoji reactions) are E2; clicking the buttons doesn't work, and if you're in the top part of the buttons (outside the message bounding box) then the message is defocused, or otherwise the tooltip for the clicked button disappears and immediately reappears on mouse-down.

mozregression narrowed it down to one commit, 9b1c242dc2e0dce955e83320a28227c9817d9d57 / bug 1798131. I also see bug 1807482, which looks similar to this one, except that it seems to be about menus in browser chrome, which I don't have problems using, and the patches from 1807482 (cherry-picked onto current m-c) don't fix this for me.

To make this more interesting, Chromium has the same issue, and I think that's been the case for a long time (at least for Duolingo; something else had broken at one point and I tried it in Chromium to troubleshoot), which suggests that there's something with these older window managers that a “normal” user wouldn't see, in order for it to stay broken for so long.

I don't really understand why the window manager has anything to do with this, because this is all about mouse enter/leave semantics inside of Web content and I don't think anything's changing with the X11 window tree… but I can't really argue with mozregression.

So this is… weird. In the attached page, mousing over the AAAA makes a popover appear; I'm using CSS for that but “real” web apps might use script instead and that could change things. With the bug, clicking on the BBBBBBBB causes that element to get, in this order: mouseleave, mousedown, mouseenter, mouseup, click. The leave/enter don't happen on release. Also, sometimes the popover visibly flickers on mousedown (i.e., the spurious leave/enter is also seen by style).

Clicking the CCCCCCCC element, like in real web content, dismisses the popover and causes a click on DDDD; in that case the sequence is: leave C, mousedown D, enter D, mouseup D, click D. (The behavior in 108 / expected behavior is that there's no enter/leave, and we see: mousedown C, mouseup C, click C.)

I ended up fixing this with a workaround. The problem has to do with dual 'grabs' on mouse buttons. I know there are fake ('pseudo') enter/leave events that are generated when you have a grab. I'm not sure if ignoring this on the WM side matters because it seems like the app (GTK3 for FF and GLFW for Chromium) still have behavior hiccups when there are dual grabs going on.

Fluxbox had a hardcoded 'grab mouse button1' for click-to-focus. I changed this to a user configured 'key'-action (see their 'keys' config). Then on focus I disable any button1 grabs on the focused windows. Everything behaves as expected. Then when It gets switched out of focus re-grab button1.

Scoured OpenBox (which works w/o modififying) and I have no clue what magic voodoo was going that allowed it to work.

Since adding a delay before, or preferrably after, the pointer replay with XAllowEvents made it possible to trigger the difficult menus, I assume there's enough inherent delay in OpenBox for GTK to not see and/or acknowledge the XAllowEvent button1-down before the fake events.

It's really baffling that this is indeed affecting web content.

Jed, if you restore the is_parent_ungrab_enter / is_parent_grab_leave code removed here, do you see the bug?

I suspect that what was papering over this was is_top_level_mouse_exit, but if it's somehow those ungrab_enter/grab_leave events, we might be able to restore some of that code. I didn't see the relevant events on Mutter/KWin, so maybe we can put it back if it fixes stuff in older WMs.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #28)

It's really baffling that this is indeed affecting web content.

Jed, if you restore the is_parent_ungrab_enter / is_parent_grab_leave code removed here, do you see the bug?

I still see the bug if I restore that code. It looks like the gdk_device_get_window_at_position hacks were the load-bearing part of this.

Another thing I don't get is: if there's a grab that's causing the leave/enter events, where is it? With the patches from bug 1807482 there's only one use of gtk/gdk grab functions I see in nsWindow.cpp, in CaptureRollupEvents, and that should be skipped if I set widget.gtk.grab-pointer to 0, but I still have the bug even with that pref change.

Reading comment #27, I'm wondering if I should be looking for grabs performed by FVWM; using ltrace I can see it calling XGrabButton on one of its windows which is the parent of the client window (for each of the first 3 buttons, with any modifiers), but I don't know if that's the kind of grab I should be looking for.

https://github.com/fluxbox/fluxbox/blob/master/src/Window.cc#L1135

XGrabButton is what I changed for Fluxbox.

Essentially swapped for this in the focus code.

XGrabButton(display, Button1, 0,   // < -- any modifier
   s_focused_fbwindow->frame().window().window(), false, ButtonPressMask,
   GrabModeSync, GrabModeAsync, None, None);

XUngrabButton(display, Button1, 0, s_focused_fbwindow->frame().window().window() );

Not/having the button grab toggles the pseudo-motion events mentioned in the commit msg I bisected. (I know the commit mentions pointer grabs and x11 docs mention pointer grabs, but afaict button grabs are causing notify leave/enter with NotifyGrab/Ungrab).

I thought the 'retry/ensure' grab part of the code was what helped, but it looks like that was re-introduced?

was reintroduce, and didnt help with a quick test*

I've found a “test case” of sorts that removes Firefox completely: xev. With some window managers, clicking in xev's window shows ButtonPress + ButtonRelease only; with others, there's also LeaveNotify + EnterNotify (+ KeymapNotify). In the WMs I've tried so far, the xev output matches what Firefox does with my previous test case.

Specifically, broken WMs include fvwm2, fvwm3, and blackbox; ones that work include openbox, wmaker, and twm(!).

Except that for fvwm, it depends on whether there's a Mouse binding for the button in question which applies to the W context (the window contents); regardless of the modifiers on the binding, it will grab the button with AnyModifiers. (In the source, see Scr.buttons2grab and the buttons_grabbed variable in ParseBinding. The former is documented as being for click-to-focus mode, but I'm not using that, so the comment may be stale… or maybe none of these button grabs are really necessary?) So, if you have meta-mouse1 bound to Move, it will also grab regular unmodified left clicks. I found a mailing list message from 1995 that came close to noticing this. On the other hand it's hard to blame fvwm here, because AFAICT there's no way to mask the modifiers you want, so you can either use AnyModifiers or iterate through every combination of modifiers you don't care about (e.g., caps lock). twm, incidentally, does appear to iterate through every combination of modifier keys.

As for what this means for Firefox: I'm not sure; this is a quirk of a few old window managers, and not even all the old window managers, and seems like a bug on their part. We could try to restore this hack that bug 1798131 removed, because I think that's what what filtering out the unwanted leaves/enters.

(In reply to zlice from comment #27)

Scoured OpenBox (which works w/o modififying) and I have no clue what magic voodoo was going that allowed it to work.

From a quick look at the openbox source, now that I know what to look for, the voodoo seeems to be the mask_list array and the loops over MASK_LIST_SIZE in grab_button_full etc. — it grabs exactly the set of sets of modifier keys it wants to handle.

I saw the same with xev as well. CTWM is similar to TWM and defaults to a 'mouse enter' for focus. Changing to a click-to-focus broke Firefox for me and generated the fake events in xev.

Also, even without my work around fix (ungrabbing), doing a shift+click allowed clicks to get picked up by Firefox and click on these kinds of problem menus. I found some 20+ year old issues while working on this about how Firefox/GTK used to not pick up clicks with mod keys, and I think that is why a lot of WMs started doing loops to bind all mod-keys. Fluxbox does the same thing as Openbox for mods. I commented out the code on both to do only a button1+buttonmask1+anymods only, and that made no difference in behavior for me.

Openbox has some kind of 'look-ahead-ignore' for the NotifyGrab/Ungrab stuff but afaict Fluxbox does similar with enters and doesn't go to process pseudo events, so, I'm still not sure what's going on behind the scenes there.

I thought it was a Fluxbox issue once I saw Openbox work but I'm wondering if they just have some kind of workaround now. The original Firefox hacks, retries and grabs were there for a reason, right? GTK has some focus docs about ignoring NotifyGrab/Ungrab if has_pointer_focus(W) (window). Not sure if that's related. Only see grab keyboard and pointer in GTK X11 code.

Trying to remember anything else that might be useful but it's getting late. Like you said, there's only the one grab in nsWindow now. Didn't explicitly look for any X errors like that '95 post but I didn't see anything and mouse button 1 worked for everything else from highlighting to moving the window around with the empty tab area.

Interested to know what's going on. Let me know if there's a build to test or you find what part of nsWindow helps.

(In reply to Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧ from comment #32)

As for what this means for Firefox: I'm not sure; this is a quirk of a few old window managers, and not even all the old window managers, and seems like a bug on their part. We could try to restore this hack that bug 1798131 removed, because I think that's what what filtering out the unwanted leaves/enters.

We'd need to restore that hack conditionally only, since for newer compositor with window decorations etc that hack prevents legit leave/enter notify events from being handled... Not sure whether that's worth it...

The bug is marked as tracked for firefox109 (beta) and tracked for firefox110 (nightly). We have limited time to fix this, the soft freeze is in 7 days. However, the bug still isn't assigned.

:gcp, could you please find an assignee for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit auto_nag documentation.

It was added in:

https://hg.mozilla.org/mozilla-central/rev/3111b73e96d8bd2fb34ad7a3c9731a2fd1ee3166

For plugins, but those are now dead and so is this message.

Gfx blocklist doesn't actually use the desktop environment filter so
remove that functionality. We can reintroduce it in the future if we
need it.

Depends on D166089

Depends on D166090

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

This should be fixed by backout for 109.0rc2. We'll still want the remaining patches from this bug to fix 110+, however.
https://hg.mozilla.org/releases/mozilla-release/rev/d6f4c3448906

https://hg.mozilla.org/mozilla-central/rev/7f78eda174d2
https://hg.mozilla.org/mozilla-central/rev/382f0839b989

The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.Also, don't forget to request an uplift for the patches in the regression caused by this fix.
• If no, please set status-firefox110 to wontfix.

For more information, please visit auto_nag documentation.

Comment on attachment 9310880 [details]
Bug 1805939 - Ignore bogus leave-notify events on known-broken environments. r=stransky!,jld!

Beta/Release Uplift Approval Request

• User impact if declined: comment 0
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• 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): Specific to some particular compositors / X servers.
• String changes made/needed: none
• Is Android affected?: No

Comment on attachment 9310880 [details]
Bug 1805939 - Ignore bogus leave-notify events on known-broken environments. r=stransky!,jld!

Approved for 110 beta 5, I will also uplift again bug 1811475 which depended on this one, thanks.

https://hg.mozilla.org/releases/mozilla-beta/rev/a95efad0e881
https://hg.mozilla.org/releases/mozilla-beta/rev/20c6743f1167

Hi, zlice! Can you please help us verify this fix on your end? It would be great to verify on all the fixed branches, if possible:

• latest Nightly 111.0a1
• Beta 110.0b5
• Release 109.0

I've tried to reproduce the issue on Ubuntu 18.04 x64, but I couldn't, and from my understating this require fluxbox or fvwm window managers to hit the bug. Unfortunately, I was not able to set up these on my machine.

Just did a quick test with the things I reported, looks like they work with Fluxbox 1.3.7. Thanks!

Thanks, zlice! I'm going to close this bug as verified fixed per your verification.