GNOME Bugzilla – Bug 740554
OSK interacts badly with Firefox and Epiphany 'awesomebar', requiring multiple keypresses to enter URLs
Last modified: 2021-07-05 13:48:07 UTC
Trying to enter a URL in Firefox's 'awesomebar' URL entry field is somewhat difficult with the GNOME OSK. Each time you enter a character, Firefox shows and updates a list of suggested completions (this is the 'awesomebar' functionality). Unfortunately it seems that clicking a key on the OSK the first time after this list is shown only causes the completion list to go away; it doesn't actually enter the character. You have to click the key a *second* time to actually enter the character (and cause an updated completion list to appear). So every character entry after the first when typing a URL into Firefox with the OSK requires two clicks on the key. This is not how a real keyboard behaves. Hitting a key just one time causes the character to be entered and the 'awesomebar' completion list to be updated. This makes using Firefox without a USB keyboard rather tedious.
This exact same behaviour is in fact visible with Epiphany as well, which does a similar 'awesomebar'-ish completion trick.
*** Bug 741124 has been marked as a duplicate of this bug. ***
there's a suggestion in #741124 to re-assign to GTK+, so let's try that.
CCing Claudio as an excuse for "what's up?" ping.
This is issue is only occurring if a gtkentry (completion) is used. As soon as a gtkentry with a popover menu is used it works without a problem. Popover menu even stays below OSK. Seems to be a problem related to the z position of the widget.
From my investigation, this is not a bug in gtk+ per-se. The completion popup is dismissed due to the "pointer emulated" ButtonPress event being replayed, so the browser receives it as a "click outside" (despite also receiving the OSK key events), and the window is hidden. The button press is however not replayed if there's no grab in effect, like in the popover case. Why does this happen deserves some more investigation, but points to mutter and upwards, I'm moving this bug to mutter.
(In reply to Jan-Michael Brummer from comment #6) > As soon as a gtkentry with a popover menu is used it works without a problem. Any test patch? :)
I haven't modified gtkentry for this purpose, but simply connected a gtkpopover to a gtkentry without completion. As a simple example just take a look at gnome maps which also implements this behaviour.
Created attachment 308035 [details] [review] Patch replacing popup window with a gtkpopover Adding a first patch for replacing gtk entry completion window with a popover. This version is finally working fine with gnome on-screen keyboard: - No longer double tapping a letter to add it to the entry field (and closing the window) - popover stays behind osk and does not interfere with it Downside: Popover can only be a part (visible) of the main window on x. PS: Sorry for this classic diff-patch, but git clone is too slow atm.
Created attachment 308036 [details] Example screenshot showing epiphany using a gtkentry with popovers
Looks funny but is actually usable on a tablet indeed, thank you!
Created attachment 308677 [details] visual comparison Thanks for the patch and screenshot, Jan-Michael! Some other applications are using popovers for their search suggestions (Maps is the example that immediately comes to mind). I have to say that I'm not entirely sure about this. Popovers are disconnected from the search box itself, and introduce more visual noise. Also: they are pointy, which means they are best used when they are triggered from a specific point on the screen. This isn't the case with a search box. I personally feel that a simple rectangular container is easier to read, coherent, and visually appealing - see the mockups for a comparison.
Note: We can somewhat reduce that noise if we simply remove the 6px border from popover. In case that it matters...
Created attachment 308679 [details] gtk entry with popover - no border
This one looks better indeed.
Created attachment 308706 [details] [review] gtk entry completion with popover and no border/frame Updated patch: Removed border and frame to make it slick.
Created attachment 308707 [details] gtk entry completion using popover and no border/frame
ping
I am sorry, but I don't think that changing the widgetry is enough of an universal fix. The same input pattern performed by GtkEntryCompletion may be (and as a matter of fact, is) implemented in other places. I see this rather as an artifact with X11, the application has (rightfully) set up an active pointer grab, so the Xserver will redirect the input to it, and there's nothing gnome-shell can do to prevail in capturing input. At this point, I rather have hopes to fix this in wayland, because there are no such input redirection concerns there (after all the compositor is in control of it). There is a newer version of the "text input" wayland protocol that's being discussed currently, which intends to cater for OSKs, once that's consolidated and implemented in mutter/gnome-shell, this will be magically fixed there.
My observation is that when people: - break all of the existing UX for something new like "touch input"; - don't actually even *try* to use their code in that target environment (e.g. GNOME < 3.14 was *completely* unusable on a tablet for me); - still blame the existing code, no new and shiny frameworks will really help the mindset. Sorry if this sounds harsh but I've actually used Plasma Active and Enlightenment with X11 on a Nexus 7 a few years ago while experimenting with ARM Linux and I don't recall a problem like this one; maybe they *did* eat their own dogfood after all. Back to the bug report: is there anything that could be done to instruct the application -- or maybe the relevant library in the whole stack busy with handling this particular event -- to avoid setting up grabs when OSK is active? Thank you for the reply!
(In reply to Michael Shigorin from comment #21) <snip misinformed rant> > > Back to the bug report: is there anything that could be done to instruct the > application -- or maybe the relevant library in the whole stack busy with > handling this particular event -- to avoid setting up grabs when OSK is > active? You can locally patch gtk+ or the X server, and enjoy a fantastically broken desktop.
We've locally patched gtk+ with Michael's popover patch from comment 10 so that typing an URL into the browser isn't fantastically broken as described. It's not a perfect solution but it *is* a solution indeed.
FWIW, as per mutter/gnome-shell master the OSK works on wayland (bug #765009), this is not an issue there.
Quick note: I can still see this issue on one of my tablets using wayland. Seems there is still a problem on wayland.
(In reply to Jan-Michael Brummer from comment #25) > Quick note: I can still see this issue on one of my tablets using wayland. > Seems there is still a problem on wayland. It works here with epiphany and gtk3-demo's entry completion demo, both with GDK_BACKEND=x11 set and unset, so you'll have to be a bit more specific... Moreover, I'd say that both related symptoms (completion window appearing on top of OSK and having to dismiss the completion window before pressing the next OSK key) are pretty much distinctive signs that you are running X11, because how override-redirect windows and grabs work. Running as a wayland compositor, mutter fully controls the stacking of the windows that were traditionally override-redirect, and there's no windowing-level grab going on which could possibly take input away from the OSK. How did you check that you're running on wayland? can you run pure-wayland clients like weston-terminal?
Thanks for your feedback, i did a complete reinstall and now it is working on every tablet. Don't know what was wrong. Sorry for the noise.
*** Bug 739636 has been marked as a duplicate of this bug. ***
*** Bug 738785 has been marked as a duplicate of this bug. ***
*** Bug 759551 has been marked as a duplicate of this bug. ***
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/mutter/-/issues/ Thank you for your understanding and your help.