Bug 255128 - www/chromium: Can't select links in dropdown menus in 89.0.4389.128
Summary: www/chromium: Can't select links in dropdown menus in 89.0.4389.128
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-chromium (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-04-16 15:36 UTC by Felix Palmen
Modified: 2021-05-07 01:02 UTC (History)
3 users (show)

See Also:
bugzilla: maintainer-feedback? (chromium)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Felix Palmen 2021-04-16 15:36:26 UTC
In the newest version of chromium, selecting a link from a drop-down menu fails and just closes the menu.

Example: Top navigation on www.freebsd.org. E.g. hover on "Documentation", move down to "Handbook", click. The menu will just close.

OS: FreeBSD 13.0-RELEASE
WM: fvwm-2.6.9_1

I didn't notice this behavior in 89.0.4389.114, but used this version only a very short time. It definitely worked correctly in 88.0.4324.182.
Comment 1 Craig Leres freebsd_committer 2021-04-16 16:59: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.
Comment 2 Tatsuki Makino 2021-04-16 21:57:29 UTC
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 :)
Comment 3 Felix Palmen 2021-05-02 12:02:50 UTC
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.
Comment 4 Matthias Wolf 2021-05-02 15:53:32 UTC
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.
Comment 5 Felix Palmen 2021-05-02 16:00:07 UTC
(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.
Comment 6 Tatsuki Makino 2021-05-02 20:04:02 UTC
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.
Comment 7 Tatsuki Makino 2021-05-05 02:56:38 UTC
The problem with comment #6 in twm has been resolved by bug 252873.
Comment 8 Craig Leres freebsd_committer 2021-05-05 04:43:48 UTC
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!
Comment 9 Felix Palmen 2021-05-06 10:16:08 UTC
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.
Comment 10 Craig Leres freebsd_committer 2021-05-06 16:57:57 UTC
(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
Comment 11 Felix Palmen 2021-05-06 19:17:16 UTC
(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…
Comment 12 Craig Leres freebsd_committer 2021-05-06 19:50:43 UTC
(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).
Comment 13 Tatsuki Makino 2021-05-06 20:29:26 UTC
What's wrong is that gecko browsers like firefox don't cause any problems :)
Comment 14 Felix Palmen 2021-05-06 21:30:24 UTC
(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 ;)
Comment 15 Felix Palmen 2021-05-06 23:05:58 UTC
(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…
Comment 16 Craig Leres freebsd_committer 2021-05-07 00:48:57 UTC
(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?
Comment 17 Craig Leres freebsd_committer 2021-05-07 00:50:03 UTC
(In reply to Felix Palmen from comment #15)
I forgot to add that your patch looks correct to me.
Comment 18 Felix Palmen 2021-05-07 01:02:06 UTC
(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 ;)