Bug 255128
| Summary: | www/chromium: Can't select links in dropdown menus in 89.0.4389.128 | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Felix Palmen <zirias> |
| Component: | Individual Port(s) | Assignee: | freebsd-chromium (Nobody) <chromium> |
| Status: | Closed Overcome By Events | ||
| Severity: | Affects Only Me | CC: | freebsd, leres, tatsuki_makino |
| Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(chromium) |
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Felix Palmen
2021-04-16 15:36:26 UTC
I've seen problems with form drop-down lists (<select>/<option>) with chromium for a really long time but have assumed it's due to my old/custom tvtwm window manager. For me, drop-downs work as long as the cursor has not been moved outside of the first chromium window I open. Once the cursor has been outside of the window then drop-down lists (including the New Tab/New Window pull down menu) will appear and then rapidly disappear. Bug 247862 is a similar report. Anyway, everything related to Chrome is strange everywhere :) Chrome Edge on Windows also has a strange back and forth relationship between the windows :) Updated to 90.0.4430.93 and unfortunately, the problem persists. Can anyone confirm? It seems that menus controlled by :hover are affected, as for example the menus on freebsd.org. This seems to be related to the WM, with Gnome it works. But then, Chromium has some WM-specific code. I'll try to track this down. (In reply to Matthias Wolf from comment #4) > This seems to be related to the WM, with Gnome it works. But then, Chromium > has some WM-specific code. Thanks. I'm using fvwm here and the problem only emerged starting with the 89.X versions of Chromium. I'm using twm as my window manager. Of course, chromium-90.0.4430.93 doesn't fix the problem of not being able to select the <select> dropdown. I can't even change bugzilla: maintainer-feedback flag in the upper right here :) twm can fix the focus on a specific window instead of the window pointed by the mouse, so <select> works fine when using it. I wrote the following to ~/.twmrc and locked the focus by rotating the wheel in the title bar. Button4 = : t : f.unfocus Button5 = : t : f.focus Drag and drop between chromium and GTK applications may not hit the right target either. The problem with comment #6 in twm has been resolved by bug 252873. Dropdowns have been broken for me in chromium for a really long time; I'm using a custom tvtwm I've been dragging along from the the 80's (yes, from the *X10* window system) and it was too simple to wedge this fix into it. Nice work! Just to clarify: dropdowns in general work fine here. What doesn't work is a menu like the top-navigation on FreeBSD.org, that is constructed of unordered lists (<ul>, <li>) with display controlled by hovering with the mouse. Clicks inside such a menu have no effect. This used to work with the same WM in earlier versions. (In reply to Felix Palmen from comment #9) My custom tvtwm does not have any problems with https://www.freebsd.org/, which window manager are you using? As far as I know the only previous-broken-but-now-fixed window manager is 1.0.11_1 of twm after this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252873#c8 (In reply to Craig Leres from comment #10) Hm, as stated above: > WM: fvwm-2.6.9_1 I now verified the same indeed doesn't happen in kwin (plasma-5). Still, fvwm2 didn't see any changes for many months now, so I assume it's a change in chromium causing this behavior. If it can't be solved, I might try getting fvwm3 to work here and see whether that helps… (In reply to Felix Palmen from comment #11) > WM: fvwm-2.6.9_1 Hah, fvwm appears to be twm based, that is it has a familiar looking add_window.c so it should be straightforward to adapt the patches added in https://cgit.freebsd.org/ports/commit/?id=1c31059e3d1233fdbaee9b89ff041365f1710d17 to x11-wm/twm to fvwm2, basically if XGetWMHints() doesn't return hints create synthetic hints. If you can't generate the patchset for fvwm2 yourself, I'm willing to (assuming you can test it). What's wrong is that gecko browsers like firefox don't cause any problems :) (In reply to Craig Leres from comment #12) Well, I now tried fvwm3 (need some fine-tuning before having a port of it to submit) and it shows the same problem. I'll still try to look for "similar looking code" there, cause this project at least is actively developed (as opposed to fvwm2), so might accept a patch in the end ;) (In reply to Craig Leres from comment #12) > basically if XGetWMHints() doesn't return hints create synthetic hints. Unfortunately, this doesn't change anything. Added this minimal change to fvwm3 1.0.2 code: --- fvwm/add_window.c.orig 2021-05-06 22:48:59 UTC +++ fvwm/add_window.c @@ -1873,6 +1873,16 @@ void setup_window_name(FvwmWindow *fw) void setup_wm_hints(FvwmWindow *fw) { fw->wmhints = XGetWMHints(dpy, FW_W(fw)); + if (!fw->wmhints) + { + fw->wmhints = XAllocWMHints(); + if (fw->wmhints) + { + fw->wmhints->flags = InputHint | StateHint; + fw->wmhints->input = True; + fw->wmhints->initial_state = NormalState; + } + } set_focus_model(fw); return; with no luck. Are you sure THIS works in your patched wm? > Example: Top navigation on www.freebsd.org. E.g. hover on "Documentation", > move down to "Handbook", click. The menu will just close. Would really be great to find out why chromium recently has a problem with fvwm… (In reply to Felix Palmen from comment #15) I run a custom version of tvtwm on my FreeBSD desktops. But it seems to closely track the twm port WRT this issue. I booted a test system and did a bunch of testing. I tested the current ports version of twm and fvwm2 and did not see any menu problems with chromium 90.0.4430.93 so maybe something changed recently? I downgraded chromium to 89.0.4389.114_1 and twm to 1.0.11 and twm had menu problems. But fvwm2 did not. I guess the question is what version of chromium do you have installed? (In reply to Felix Palmen from comment #15) I forgot to add that your patch looks correct to me. (In reply to Craig Leres from comment #16) >I guess the question is what version of chromium do you have installed? I guess the question *now* is: what in the world could be different on my machine? The problem first appeared with some chromium 89 version (probably the one from the title although I'm not entirely sure about that) and persists with chromium-90.0.4430.93 installed now. And as for fvwm2: it doesn't move any more ;) The issue disappeared for me in chromium 92.0.4515.159 \o/ |