1567425 - Focused password field has high CPU usage and delayed input on Ubuntu 18.04.1 LTS

Status: RESOLVED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[Kestrel]

STR:

1. Focus on a password field and start typing on Ubuntu 18.04.1 LTS.

Note high CPU usage and delayed character entry while password field is in focus.

Workaround is to start with env GTK_IM_MODULE=xim firefox.

Ubuntu 19.04 is unaffected.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=508dd8a2213655da99d4a9b49b8fa6dc68bd0821&tochange=6977e33ca9496ff2c8b4b9feeace89307aed07ec

Regressed by Bug 1524975.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Can't reproduce on Fedora 29.

Could you perhaps provide a performance profile using https://profiler.firefox.com/
(obviously when using Ubuntu 18.04)

Comment 2

[Kestrel]

(In reply to Olli Pettay [:smaug] (pto until July 28) from comment #1)

Can't reproduce on Fedora 29.

Fedora 29 was released halfway between Ubuntu 18.04 and 19.04 so that's not unexpected.

Could you perhaps provide a performance profile using https://profiler.firefox.com/
(obviously when using Ubuntu 18.04)

https://perfht.ml/2GpH7CM

Comment 3

[Henri Sivonen (:hsivonen)]

Looks like IME focus and blur in IBus are taking excessive time on the IBus side in the profile.

Preliminary observation: Something weird has happened with IBus in Ubuntu 18.04 while I was away. This morning, I installed updates that have queued up while I was away and now all IBus-based IMEs that I have enabled don't actually show up in the input switcher.

Reporter, which input method did you have active when observing this? Which other input methods do you have in the menu ready to be switched to? Are you running the Ubuntu-default Gnome desktop?

Comment 4

[Henri Sivonen (:hsivonen)]

Also, the profile suggests that the IME focus and blur come from windows getting raised and lowered. Do you have focus-follows-mouse or some other special feature enabled that could cause frequent and rapid window raising and lowering?

Comment 5

[Henri Sivonen (:hsivonen)]

(In reply to Henri Sivonen (:hsivonen) from comment #3)

and now all IBus-based IMEs that I have enabled don't actually show up in the input switcher.

Correction: It turns out that all the IMEs vanish from the menu when focus is in a password field. They show up otherwise. So if I first have U.S. English keyboard active, then switch to Japanese IME in Latin mode (i.e. U.S. keyboard behavior implemented via the Japanese IME), if I tab to a password field, the input method reverts to the actual U.S. English keyboard but if I tab out of the password field, the Japanese IME (still in Latin mode) is reactivated.

Masayuki, is that intended behavior with IBus?

I tested on a fast computer and didn't see any performance problem with this, though.

Comment 6

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

if I tab to a password field, the input method reverts to the actual U.S. English keyboard but if I tab out of the password field, the Japanese IME (still in Latin mode) is reactivated.

Masayuki, is that intended behavior with IBus?

Yes, it is. We intend to disable (close) IME only in password fields (and ime-mode: disabled;) temporarily since most users don't want us to switch active keyboard layout/IME automatically.

As you mentioned, im_module_list in im-ibus.so takes too long time when we call gtk_im_context_focus_in() and gtk_im_context_focus_out().

I guess that reporter uses Unity and Unity uses focus move for doing something and that causes calling them a lot in new design. See bug 1451466.

Comment 7

[Henri Sivonen (:hsivonen)]

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(Still struggling with the pain, but becoming better) from comment #6)

I guess that reporter uses Unity and Unity uses focus move for doing something and that causes calling them a lot in new design. See bug 1451466.

Ah, the bug only affects Gnome (Mutter) in an X.org session. I used the Wayland session for testing.

Reporter, the bug was supposed to have been fixed in gnome-shell 3.28.3-0ubuntu0.18.04.4 in the Ubuntu 18.04 series. What version of gnome-shell do you have? (I think I have the latest, and mine is 3.28.3+git20190124-0ubuntu18.04.2 .)

Comment 8

[Henri Sivonen (:hsivonen)]

Reporter, does lsb_release -a report 18.04.1 for you? It's supposed to report 18.04.2 by now if updates are properly applied.

Comment 9

[Kestrel]

Test environment of initial report was 18.04.1 LTS live ISO without alterations. I can confirm that 18.04.2 LTS live ISO fixes the issue with release 68.0.1 and latest Nightly 70.0a1. I should have tested with this newer ISO in the first place, sorry for the noise.