SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
The Chrome browser "File" menu (Alt+F or the vertical ellipsis button) and all right-button context menus unpost immediately after being posted. It's impossible to use them because they unpost too quickly to click on. The problem in my case is window manager specific. I use twm (Tom's Window Manager).
No associated messages in the session logfile.
A Google search reveals other people have had a similar issue. My experience with the various solutions I found is:
Turning off the Chrome option Use hardware acceleration when available did not help.
Restarting Chrome is a temporary solution if it works at all. When it does work, moving, resizing, or lowering the Chrome window brings the problem back.
Trying another window manager worked around the problem. The issue does not arise when I use mwm (Motif Window Manager).
Chrome 111.0.5563.64 installed using upgradepkg from google-chrome*.txz.
This is created by slackware64-15.0/extra/google-chrome/google-chrome.SlackBuild.
The slackbuild derives it from google-chrome-stable_current_amd64.deb.
So this happens only in chrome and not anywhere else?
There may be some setting to disable chrome "decorator" in settings, set it to use window decoration from your WM.
Otherwise, I don't know. Maybe WM is configured to do that, so you then might have to hold LMB1 to keep menus open.
So this happens only in chrome and not anywhere else?
There may be some setting to disable chrome "decorator" in settings, set it to use window decoration from your WM.
Otherwise, I don't know. Maybe WM is configured to do that, so you then might have to hold LMB1 to keep menus open.
Yes, only in Chrome.
It does not look like a window manager configuration is responsible. After starting Chrome, the menus often work normally before performing any window manager action (such as move, raise/lower, resize). Configuration should give me consistently wrong behavior, not inconsistently wrong behavior.
Doesn't matter whether a mouse button is held down. When the problem is present, the context menu unposts instantly after it is posted. If posted using the mouse, it does not help to hold the mouse button down. If posted using the keyboard, the behavior is the same: unposts instantly.
Not using it, but from past experience: it's a binary compiled for a different system, don't expect too much.
Nobody at google tested it on TWM. Maybe debian maintainer did, but I would not bet on that.
Have you tried to repeat the issue with the chromium package from AlienBob, that is (or used to be) compiled on Slackware for Slackware?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.