1552445 - focus loss on keyboard layout switch

Status: REOPENED

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

Description

[Konstantin Kivi]

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

Steps to reproduce:

All test are done on a clean firefox profile, with now extension enabled
Use Linux with gnome GUI ( ubuntu 18.10 ) in my case
Have multiple languages input configured in your system (English and Russian in my case)

press a pocket sign next to url and start editing tags
OR
open duckduckgo.com and start typing in search field
OR
open wunderlist.com ( provided you have an account, which is free ), press AddTask and start typing

AND then switch keyboard layout with a corresponding hot key combination.

Actual results:

input language changes but focus is lost and in case of pocket - entry field closes.

I suppose - it happens only in certain javascript enabled pages.

Expected results:

input language should change and you must be able to continue typing in a new language.

Comment 1

[Konstantin Kivi]

chrome is not affected by this bug!

Comment 2

[Rares Doghi, Desktop QA]

Hi Konstantin, I managed to reproduce this issue in Firefox 66.0.5 , RC 67 and our latest Nightly 69.0a1 (2019-05-21) using this site wunderlist.com, it seems that every time you change the language its loosing focus of the field, It does not happen however in the extra Search bar added from preferences.

Also for the pocket issue it might be intended to disappear since clicking anywhere else or clicking the Windows button on the keyboard closes any pop ups displayed.

I'm not sure if this is the correct component for this issue but it seems like a good place to start, please change it to a more suitable component if its not the correct one.

Comment 3

[Konstantin Kivi]

Hi, Rares, thank you for the fast feedback.

As to pocket, It could not be normal behaviour, because keyboard layout is
normally switched via special key combination, and not mouse click, which might pose problem indeed.

Unfortunately, I am not mozilla firefox developer
and don't know if there is a better component for reporting this bug.

Comment 4

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

Masayuki, do you have ideas where it can go wrong in the code?

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Hmm, I still don't understand what's going on.

First, when user tries to change keyboard layout, Ubuntu shows list of keyboard layouts with popup window. It steals focus from us. This behavior is by design of Ubuntu. So, we cannot do anything for this. (I.e., we cannot support keyboard layout switching in popup windows like bookmark panel.)

Then, when user selects a keyboard layout, it restores focus to our window. When I open DuckDuckGo, the window is activated twice and then, IME handler receives "blur" from content. Actually the our focus manager moves focus to outside the search field of DuckDuckGo. When I test same steps with simple testcase, similarly, I see the double window activation too, but I don't see the last "blur" from content. So, DuckDuckGo might do something or we dispatch wrong event.

Comment 6

[Konstantin Kivi]

Hi, Masayuki
Maybe the following facts will help

1. Ubuntu allows to switch keyboard with a hotkey, without displaying popup window
2. Neither example I provided exhibits this problem.

This is a screenshot showing keyboard configuration.
https://www.dropbox.com/s/fdeqel4o4onx7h1/Screenshot%20from%202019-05-27%2015-56-24.png?dl=0

BR, Konstantin

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:hsinyi, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 9

[Henri Sivonen (:hsivonen)]

Duplicating forward, because the other bug has a better test case and more information, such as the observation that this problem is specific to the X session and the Wayland session does not have this problem.

Comment 10

[sempasha]

Maybe it is duplicate of 1615867, but in case of duckduckgo.com search input lost focus forever (single blur event) after keyboard layout switch, while issue 1615867 describes loosing focus for a moment (pair of blur/focus events).

Comment 11

[Konstantin Kivi]

Firefox 77.0.1 (64-bit), ubuntu 20.04
Bug is still present.

Comment 12

[Xidorn Quan [:xidorn] UTC+10]

I think this and bug 1615867 are the same bug.

Some websites may choose to blur the input when the page lose the focus, causing the focus comes back to the input when this happens, while others don't. In that bug, I also mentioned this issue.

As an evidence, on DDG, if you register event listener for focus and blur on document, you can see the events also shows in pairs with focus being the last, but the focus on input just never comes back.

However, that bug was filed after this, so I think that should be duped into this, rather than the other direction.

Comment 14

[Xidorn Quan [:xidorn] UTC+10]

I have a patch which seems to work. Doing a try push to see if it breaks any test.

Comment 15

[Xidorn Quan [:xidorn] UTC+10]

My idea is basically to rely on window state change on GDK_WINDOW_STATE_FOCUSED bit rather than using the focus events. This follows the same way of how we determine which state to show on the title bar, and it does fix the temporary loss of keyboard focus for IM switch and Alt-Tab switch (as those triggers focus event change but not window state change).

The problem is that it changes the timing of the events, and thus seemingly breaks tons of tests. Specifically, it seems at the moment a new window is shown, it quickly changes to focused state and back, making the focus manager consider no window is focused, however, the existing window doesn't get any state change, so it's still considered focused on the widget level, and thus doesn't trigger a focus when SetFocus is invoked. This makes waitForFocus more unreliable.

It's not fully clear to me what can be done for this situation...

Comment 16

[Xidorn Quan [:xidorn] UTC+10]

It seems that at least on my desktop environment (GNOME Shell 3.36 on X), a new window created would all experience

window state change: focused to true
window state change: focused to false
focus in
focus out
window state change: focused to true
focus in

and when creating a new window, the whole process would be:

NEW: window state change: focused to true
NEW: window state change: focused to false
OLD: focus out
NEW: focus in
NEW: focus out
OLD: window state change: focused to false
NEW: window state change: focused to true
NEW: focus in

This indicates that if we can somehow ignore the initial event sequence, it would likely behave in the expected way, as the relative order between focus events and that between state change events are the same.

The question then, is how do we distinguish the initial two state change...

Comment 17

[Nikolai Zhubr]

I'm wondering if this bug is what I observed recently at my friend's Ubuntu notebook and FF65 on some sites. Because I was asked for advice how to fix/workaround the issue I'm now trying to figure. The behaviour was quite horribly broken and likely focus-related. That is, edit fields were loosing focus not only when trying to switch input language but also when pressing Shift key alone, thus essentially preventing input of capital letters. Maybe GTK was trying to do some very smart visual feedback on some system keypresses or alike, causing FF to think that it lost focus briefly, not sure. Additionally, all this focus mess affected text (auto-)selection, so pressing some next letter at unfortunate time was causing previous input to be unintentionally wiped out. Just a total disaster! Meanwhile, here with opensuse, there is no such problem at all. Now that I see this bug is still open, is there any hope? Is there any reasonable workaround? Is it clear why it is not observed anywhere other than Ubuntu? Thanks.

Comment 18

[kuzdra]

I'd like to chime in and add a seemingly new data point. I've been experiencing this bug on Fedora as well. I can reproduce it as I write this on an up-to-date system.

I run Firefox 86.0.1 on Fedora 33, GNOME 3.38.4, GTK 3.24.27 under X11.
(I cannot reproduce the bug on Chromium 88.0.4324.182.)

I am happy to provide more details or run small tests upon request.

Comment 19

[Nikolai Zhubr]

I'm no expert in creating web-browsers, but as a user, I'd say I find this entire focus-tracking "feature" conceptually broken. Although there might indeed be some rare cases of moderately reasonable use, most of the time it is a path to unnecessary overcomplication, annoying excessive visual feedback, massive portability problems and abusive web-programming.
A webpage normally should have no business of tracking what is happening on the desktop surrounding it anyway, and that includes tracking input focus changes (except maybe moving focus between parts of the webpage itself, but it is a different story).
At least, there should be some easily accessible setting provided for a user to disable all this hell if necessary.

Comment 20

[ZaWertun]

FYI: I can reproduce this bug on Fedora 33 KDE Sping after installing & using ibus for layout switching.
Removing ibus from the system and killing all ibus processes solves the issue.
(I've been using KDE on X11).

Comment 21

[Nikolai Zhubr]

Attachment: gtk_focus_fix.diff

This patch eliminates repetitive crazy gtk focus in/out events dispatching. As a side effect, it also eliminates regular focus-out events along with, but that is really much less of a trouble for end user, if at all.
To my knowledge, the result is very positive at least on Ubuntu 16.04.

Because rebuilding FF from source consumes quite a lot of time and RAM and disk space, here is a binary tarball for quick test for Ubuntu: https://disk.yandex.ru/d/5UcMv5nxrX-vEg (Please see a Download button).

I do not have a build for Fedora but the patch itself is obviously distro-neutral and should have effect as long as gtk widgetset is involved, just be sure to have rpmbuild at hand and 35+ Gb of free disk space.

(Personally I'm using suse and am not seeing this issue here yet for whatever reason.)

Comment 22

[Xidorn Quan [:xidorn] UTC+10]

Attachment: patch

FWIW, I believe this patch is the right approach to fix the issue. The only problem, as I noted in comment 15 and 16, is that it changes the focus changing order, and breaks lots of automated tests, which I have no clue how to fix.

Comment 23

[Xidorn Quan [:xidorn] UTC+10]

I'm going to unassign myself from this bug as I don't think I have the expertise and time to dig into that issue currently... Anyone feel free to use the WIP patch above and continue the investigation.

Comment 24

[Aurelijus]

Disclaimer: I do not have enough knowledge to help this in any way, just writing as a consumer: this bug is killing me :/ I am on latest ubuntu and 91.0 Firefox and curse every time this messes my input. Can we have any reasonable hack (read: not changing code and compiling browser) to fix it? I am thinking about shopping for new browser and I would hate it because I love FF very much...

Comment 25

[Nikolai Zhubr]

(In reply to Aurelijus from comment #24)

Disclaimer: I do not have enough knowledge to help this in any way, just writing as a consumer: this bug is killing me :/ I am on latest ubuntu and 91.0 Firefox and curse every time this messes my input. Can we have any reasonable hack (read: not changing code and compiling browser) to fix it? I am thinking about shopping for new browser and I would hate it because I love FF very much...

Have you tried my precompiled tarball from comment 21? Although it was built for Ubuntu 16, I think there are some chances it could work on later versions too. (Note: this binary build is configured to run from any user-owned folder, like ~/Desktop/tests, and it will stay within a folder you choose to extract it into, and will co-exist peacefully with whatever other standard version of FF you have installed globally)

I suppose it is unlikely this problem can be really solved without modifying code. Changing some GTK/desktop settings might help, but no specific recipe exists yet. If there was enough interest from FF developers to fix it, it might eventually happen that you just get a fix with some regular update. Unfortunately though, it looks like FF developers have exactly zero interest :(

Comment 26

[Aurelijus]

(In reply to n-a-zhubr from comment #25)
Yes, it does work! Only there is a problem that the text cursor in input fields is not displayed :) But that maybe not related.

Comment 27

[Nikolai Zhubr]

(In reply to Aurelijus from comment #26)

(In reply to n-a-zhubr from comment #25)
Yes, it does work! Only there is a problem that the text cursor in input fields is not displayed :) But that maybe not related.

Thanks for testing :) At least we have a proof of concept now.
It would be nice to also find out how to reliably reproduce the issue starting from OS installation, because some people report they are affected, some not.
(I'm using openSuse and am not affected, neither I could reproduce it inside a VM here)

Comment 28

[pva]

(In reply to n-a-zhubr from comment #21)

Created attachment 9214353 [details] [diff] [review]
gtk_focus_fix.diff

@n-a-zhubr, could you, please, update this patch for firefox 114?

Comment 29

[Nikolai Zhubr]

(In reply to pva from comment #28)

(In reply to n-a-zhubr from comment #21)

Created attachment 9214353 [details] [diff] [review]
gtk_focus_fix.diff

@n-a-zhubr, could you, please, update this patch for firefox 114?

What distro are you using? Do you observe this bug with standard distro-supplied package? Are you going to rebuild it youself? I'm asking because I do not have any system showing this bug readily at hand now, and building firefox is somewhat time-consuming and space-consuming thing. I might try, but at least I'd like it to be usefull.

Comment 30

[pva]

(In reply to n-a-zhubr from comment #29)

What distro are you using? Do you observe this bug with standard distro-supplied package? Are you going to rebuild it youself? I'm asking because I do not have any system showing this bug readily at hand now, and building firefox is somewhat time-consuming and space-consuming thing. I might try, but at least I'd like it to be usefull.

I'm using Gentoo Linux, and yes, this is self-built firefox with the following USE flags:
114.0 X clang dbus geckodriver gmp-autoupdate hwaccel jumbo-build lto openh264 pgo pulseaudio system-av1 system-harfbuzz system-icu system-jpeg system-libevent system-webp telemetry wayland wifi -debug -eme-free -hardened -jack -libproxy -screencast -selinux -sndio -system-libvpx -system-png -system-python-libs -valgrind

But since this was a problem on different distributions with a (partially) deprecated xorg I don't think this issue deserves lot's of time. Still I very much appreciate the patch I could try to apply during build and use.

BTW, if it helps I can try the official build for firefox to see if this issue is reproducible there.

Comment 31

[Henri Sivonen (:hsivonen)]

Masayuki, do you have ideas how to move this forward in the light of comment 22?

Comment 32

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I don't know. I'm not so familiar with GTK/GDK event models without investigating it...

Comment 33

[Nikolai Zhubr]

Attachment: gtk_focus_fix_104.diff

Updated patch for version 104. Not tested in any way.

Comment 34

[Nikolai Zhubr]

(In reply to pva from comment #30)

I'm using Gentoo Linux, and yes, this is self-built firefox with the following USE flags:
114.0 X clang dbus geckodriver gmp-autoupdate hwaccel jumbo-build lto openh264 pgo pulseaudio system-av1 system-harfbuzz system-icu system-jpeg system-libevent system-webp telemetry wayland wifi -debug -eme-free -hardened -jack -libproxy -screencast -selinux -sndio -system-libvpx -system-png -system-python-libs -valgrind

But since this was a problem on different distributions with a (partially) deprecated xorg I don't think this issue deserves lot's of time. Still I very much appreciate the patch I could try to apply during build and use.

BTW, if it helps I can try the official build for firefox to see if this issue is reproducible there.

Hi, please try gtk_focus_fix_104.diff
It should apply cleanly to unmodified vanilla source.
I was not able to test it in any way, but the update was quite trivial so I think it could work.

And someone of Mozilla please at least mark firefox version 104 as affected too.
Thanks.

Comment 35

[Nikolai Zhubr]

(In reply to Nikolai Zhubr from comment #33)

Created attachment 9342891 [details] [diff] [review]
gtk_focus_fix_104.diff

Updated patch for version 104. Not tested in any way.

Same patch can also be applied to 115esr (with some offsets but that's harmless and automatic) and likely anything in between.