Open Bug 1836632 Opened 2 years ago Updated 3 months ago

[X11/TWM] mouse action changed - can no longer do some things, like edit bookmark

Categories

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

Product:
Core
Component:
Widget: Gtk
Version:
Firefox 113
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: aeb, Unassigned)

References

Details

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

Steps to reproduce:

Click the star to add a bookmark. A popup window "Edit bookmark" appears as soon as the mouse button is released. Move the mouse pointer towards the popup window. It immediately disappears again.

Actual results:

See above.

Expected results:

I should be able to edit a bookmark. For example, the popup window should appear on mouse button press, and stay while the mouse button is pressed. Or otherwise it should appear when the mouse button is released and stay until some action has happened in the popup window.

The Bugbug bot thinks this bug should belong to the 'Firefox::Bookmarks & History' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Bookmarks & History

The severity field is not set for this bug.
:mak, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(mak)

(In reply to aeb from comment #0)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/113.0
Click the star to add a bookmark. A popup window "Edit bookmark" appears as soon as the mouse button is released. Move the mouse pointer towards the popup window. It immediately disappears again.

If you type something or click on something in the panel it should not close. If you move the mouse over the panel, it should also reset the timer.
It closes after 3.5 seconds if the mouse doesn't move and there has been no interaction (clicks or keypress).
I wonder if this is just another case of Bug 1809747, where the timeout is just too short.

Could you please share some additional info about your OS, which distribution and window manager are you using?
A screencast of the issue may also be useful.

Flags: needinfo?(mak) → needinfo?(aeb)

If you type something or click on something in the panel it should not close.

It is impossible to click on something in the panel since it closes immediately as soon as it is entered, with zero timeout (or at least, a timeout much shorter than 0.1 sec).

If you move the mouse over the panel,

It is impossible to move the mouse over the panel since it closes immediately as soon as it is entered.

additional info about your OS, which distribution and window manager are you using?

This is a vanilla Ubuntu Linux "Ubuntu 20.04.6 LTS". The Window manager is twm.

Flags: needinfo?(aeb)

What happens if you click the star button a second time? Does the edit bookmark dialog stay open?

If it does stay open, look near the bottom of the dialog, there should be a "Show editor when saving" button. Ensure that has a tick in it, then click one of the two buttons.

After that, try bookmarking a different page. Does that help?

Flags: needinfo?(aeb)

What happens if you click the star button a second time?

The same as the first time. The edit bookmark dialog closes immediately when it is entered.

Flags: needinfo?(aeb)

Please can you try opening the browser console by going to the three-bar menu -> More Tools -> Browser Console.

After that, switch back to the main window and try opening the edit bookmark dialog again. Then see if any errors have appeared on the console. If so, please copy/paste them here.

No, I see no new messages on the browser console.

My bug title "mouse action changed" is seen also here (and in many other places): In the good old days it was easier to navigate menu hierarchies.
In order to go to the browser console I click the triple bar. If I release the mouse, the corresponding menu disappears as soon as it is entered.
So I keep the mouse button pressed, enter the dialog, go down to More Tools, release the mouse button there and click on More Tools, release the mouse button (that is possible since I am now already inside the More Tools dialog) and click Browser Console.

Keeping the mouse button pressed does not work in the bookmark case, since there the dialog first appears upon mouse button release.

The severity field is not set for this bug.
:mak, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(mak)

(In reply to aeb from comment #8)

In order to go to the browser console I click the triple bar. If I release the mouse, the corresponding menu disappears as soon as it is entered.

Ok, there is definitely something wrong in your OS/WM settings if the menus don't stay open. Maybe you have some option enabled at system level to move focus with the mouse, or the WM is somehow broken. That "triple bar" menu once clicked must stay open, and that's likely the same issue causing your bookmarks panel problems.

Component: Bookmarks & History → Widget: Gtk
Flags: needinfo?(mak)
Product: Firefox → Core

Please attach your about:spport page and also try to create a screencast of the issue:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Collect_information_for_a_bug_report
Thanks.

Flags: needinfo?(aeb)

something wrong in your OS/WM settings

Well, these settings have not changed in decades, but the firefox behavior changed.
Long ago twm was the default window manager for X, and I am still using it.
I just killed twm and repeated the action without window manager, on bare X, and all stayed the same: I click on triple bar, move the mouse around outside the corresponding menu, and the menu stays open, but it closes the moment the mouse pointer enters it.

screencast

My first attempt failed. Maybe my text description is clear and unambiguous, and no additional video is useful.

about:support

The entire page cannot be given because of privacy and security reasons. If you want any details, ask.

Name Firefox
Version 114.0.2
Build ID 20230619081400
Distribution ID canonical
User Agent Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/114.0
OS Linux 5.4.0-152-generic #169-Ubuntu SMP Tue Jun 6 22:23:09 UTC 2023
OS Theme Yaru / Adwaita
Application Binary /usr/lib/firefox/firefox
Window Protocol x11

Flags: needinfo?(aeb)

I tested what versions of Firefox do this premature closing of menus.
In version 109.0.1 all is well. In version 110.0.1 the triple bar menu closes as soon as it is entered.

Can you use mozregression tool to find broken commit?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Use_Mozregression_tool
Thanks.

Flags: needinfo?(aeb)

My first attempt failed:

pip install mozregression

Collecting mozregression
Collecting mozinfo>=1.1.0
Collecting mozprocess>=1.3.1
...
Collecting importlib-resources>=1.4.0; python_version < "3.9"
Collecting jsonschema-specifications>=2023.03.6
Collecting referencing>=0.28.4
Collecting rpds-py>=0.7.1
Collecting zipp>=3.1.0; python_version < "3.10"
Successfully built mozinfo mozlog
ERROR: referencing 0.30.0 has requirement attrs>=22.2.0, but you'll have attrs 19.3.0 which is incompatible.
ERROR: jsonschema 4.18.4 has requirement attrs>=22.2.0, but you'll have attrs 19.3.0 which is incompatible.

$ mozregression --good 109.0.1 --bad 110.0.1
Traceback (most recent call last):
...
ModuleNotFoundError: No module named 'attrs'

Flags: needinfo?(aeb)

2nd attempt:

$ pip install --upgrade attrs
$ pip install mozregression
Successfully installed mozregression-5.6.0

$ mozregression --good 109.0.1 --bad 110.0.1
...
3:28.09 INFO: Narrowed integration regression window from [8e6e771d, d722b252] (3 builds) to [48181532, d722b252] (2 builds) (~1 steps left)
3:28.09 INFO: No more integration revisions, bisection finished.
3:28.09 INFO: Last good revision: 48181532b788f8b28d5a9ebe88028e585bf6e4ef
3:28.09 INFO: First bad revision: d722b25231b9e10755c0efc93a2df8891676213d
3:28.09 INFO: Pushlog:
https://hg.mozilla.org/releases/mozilla-release/pushloghtml?fromchange=48181532b788f8b28d5a9ebe88028e585bf6e4ef&tochange=d722b25231b9e10755c0efc93a2df8891676213d

Oh, that's pretty big regression range. Not sure we can extract any useful info from it but thanks anyway.

Summary: mouse action changed - can no longer do some things, like edit bookmark → [X11/TWM] mouse action changed - can no longer do some things, like edit bookmark
Priority: -- → P3

See Comment 12:

"I just killed twm and repeated the action without window manager, on bare X, and all stayed the same: I click on triple bar, move the mouse around outside the corresponding menu, and the menu stays open, but it closes the moment the mouse pointer enters it."

This means that the "/TWM" part of the title may be misleading: twm is not needed to get this effect.

"> screencast
My first attempt failed. Maybe my text description is clear and unambiguous, and no additional video is useful."

For the time being I regard this as time-consuming and meaningless work. If there is anything concrete you want to know, ask.

Flags: needinfo?(aeb)

Recently the amount of mouse focus problems increased so as to make firefox almost unusable.
Following a suggestion from elsewhere I added "export XDG_SESSION_DESKTOP=twm" before invoking twm. That helped.
Today I retested the present bug on firefox 120.0.1. It is gone.

See Also: → 1805939

Did you have set XDG_SESSION_DESKTOP at all before your explicit change?

Flags: needinfo?(aeb)

All of the above discussion, up to and including Comment 19, was without setting XDG_SESSION_DESKTOP.
In Comment 20 I report that after setting XDG_SESSION_DESKTOP to twm the bug discussed here has vanished on firefox 120.0.1.
Today I rechecked: without setting XDG_SESSION_DESKTOP the bug is still present, after setting XDG_SESSION_DESKTOP to twm it is gone, this time on (Ubuntu) firefox 121.0.

Flags: needinfo?(aeb)

Looks like it.

I am also seeing this bug, on Firefox 122 with twm on Arch. I just switched to twm and have nothing customized in the twm config. It's inconvenient to use the menus this way. Some menus, for example the language translations button in the url bar, are impossible to use because you can't get past the first popup. I can also confirm that in Firefox 108 all was well.

To sum up, the bug is in nsWindow.cpp: sSystemNeedsPointerGrab. It wants to know whether the window manager is operating in a click-to-focus or focus-follows-mouse model. It does this in a completely broken way, by trying to check what "desktop" is running. Since it has confused desktops with window managers, the check doesn't work. But even if it did, it would be wrong. You can't check for focus-follows-mouse by looking to see what window manager is running. This would require enumerating every window manager, all those that have ever existed, all those that exist now, and all those that will exist in the future. This is clearly impossible. But even if it were possible, it would still be wrong, because there are window managers (Openbox is an example) that can operate either way.

The fundamental problem here is that Firefox is trying to impose its will on the window manager instead of allowing the window manager to do its job unmolested. I am sure this will never be fixed. But ignoring this, Firefox is broken in the following ways:

  1. It thinks it can discover what window manager is running by checking XDG_SESSION_DESKTOP
  2. It thinks it knows about every window manager that has ever been written and all that ever will be written
  3. It thinks that a window manager will only ever have a single focus model
  4. It thinks it know better than the window manager how to manage windows

I can't suggest a fix here because the entire model is wrong and needs to be re-evaluated, and the code re-written. This should be done with an eye toward allowing the window manager to manage the windows.

(In reply to Jim Rees from comment #26)

I can't suggest a fix here because the entire model is wrong and needs to be re-evaluated, and the code re-written. This should be done with an eye toward allowing the window manager to manage the windows.

Good, but I'm afraid we don't have any better solution yet. Please feel free to investigate, propose and implement something better. We're always open for better ideas and improvements.

There's also a Firefox hacking mini-howto available here:
https://mastransky.wordpress.com/2023/07/04/no-one-fights-alone-a-guide-to-your-first-firefox-patch-on-linux/

Thanks.

The code is broken and should never have passed QA, much less been commited. If you have no better solution, the commit that added this code should be reverted.

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