1451466 - [New in Ubuntu 18.04] When <input type="password"> field changes focus, full browser is blurred and then refocused (causing jank & causing autohiding menus to hide & breaking some login forms))

Status: RESOLVED INVALID

(Core :: Widget: Gtk, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: test.html

(spinning this off as the root cause of bug 1451418, now that I have simpler STR that don't require an extension)

STR:
 1.  Install Ubuntu 18.04 (liveCD environment probably works -- http://cdimage.ubuntu.com/daily-live/current/ )

 2. Start Firefox Nightly with environmental variable MOZ_LOG="Focus:4"

 3. Tab through the fields in the attached testcase.

EXPECTED RESULTS:
 - Nothing overly expensive should happen when the <input type="password"> field gains focus.

ACTUAL RESULTS:
 - The logging in your terminal (from MOZ_LOG="Focus:4") shows that the full browser is blurred (loses focus) and then becomes focused again.
 - This causes some jank as can be seen by the red bar (and work associated with "WindowLowered") here:  https://perfht.ml/2GTdgE1
 - If the password field is in a popup, this may make the popup disappear, whcih breaks extensions like BitWarden -- see bug 1451418.


With latest Nightly on Ubuntu 17.10, I get EXPECTED RESULTS.
With latest Nightly on Ubuntu 18.04, I get ACTUAL RESULTS.

Comment 1

[Daniel Holbert [:dholbert]]

Here's what the logging looks like for a "normal" focus change (when I hit "Tab" to move from the number-input widget to the textarea).  Note that 7411 is the PID of my content process here.

[7411:Main Thread]: D/Focus <<MoveFocus begin Type: 1 Flags: 2000>>
[7411:Main Thread]: D/Focus  Focused Window: 0x7fce9aab92a0 file:///tmp/test.html
[7411:Main Thread]: D/Focus   Current Focus: input                               
[7411:Main Thread]: D/Focus Shift Focus: textarea                                
[7411:Main Thread]: D/Focus  Flags: 2000 Current Window: 0x7fce9aab92a0 New Window: 0x7fce9aab92a0 Current Element: 0x7fcea1f836a0
[7411:Main Thread]: D/Focus  In Active Window: 1 In Focused Window: 1 SendFocus: 1
[7411:Main Thread]: D/Focus <<Blur begin>>
[7411:Main Thread]: D/Focus Element input has been blurred                 
[7411:Main Thread]: D/Focus Update Caret: 0 1
[7411:Main Thread]: D/Focus Update Caret: 0 1
[7411:Main Thread]: D/Focus <<Focus begin>>
[7411:Main Thread]: D/Focus Element textarea has been focused
[7411:Main Thread]: D/Focus  from html
[7411:Main Thread]: D/Focus  [Newdoc: 0 FocusChanged: 1 Raised: 0 Flags: 2000]
[7411:Main Thread]: D/Focus Update Caret: 1 0
[7411:Main Thread]: D/Focus <<MoveFocus end>>



In comparison, here's what the logging looks like when I hit "Tab" again to enter the password field (note that some of the logging in the middle is for the parent process, PID 6975):

[7411:Main Thread]: D/Focus <<MoveFocus begin Type: 1 Flags: 2000>>
[7411:Main Thread]: D/Focus  Focused Window: 0x7fce9aab92a0 file:///tmp/test.html
[7411:Main Thread]: D/Focus   Current Focus: textarea
[7411:Main Thread]: D/Focus Shift Focus: input
[7411:Main Thread]: D/Focus  Flags: 2000 Current Window: 0x7fce9aab92a0 New Window: 0x7fce9aab92a0 Current Element: 0x7fceb6fa87a0
[7411:Main Thread]: D/Focus  In Active Window: 1 In Focused Window: 1 SendFocus: 1
[7411:Main Thread]: D/Focus <<Blur begin>>
[7411:Main Thread]: D/Focus Element textarea has been blurred
[7411:Main Thread]: D/Focus Update Caret: 0 1
[7411:Main Thread]: D/Focus Update Caret: 0 1
[7411:Main Thread]: D/Focus <<Focus begin>>
[7411:Main Thread]: D/Focus Element input has been focused
[7411:Main Thread]: D/Focus  from html
[7411:Main Thread]: D/Focus  [Newdoc: 0 FocusChanged: 1 Raised: 0 Flags: 2000]
[7411:Main Thread]: D/Focus Update Caret: 1 0
[7411:Main Thread]: D/Focus <<MoveFocus end>>
[6975:Main Thread]: D/Focus Window 0x7f5e7b0792a0 Lowered [Currently: 0x7f5e7b0792a0 0x7f5e7b0792a0]
[6975:Main Thread]: D/Focus   Lowered Window: chrome://browser/content/browser.xul
[6975:Main Thread]: D/Focus   Active Window: chrome://browser/content/browser.xul
[6975:Main Thread]: D/Focus <<Blur begin>>
[6975:Main Thread]: D/Focus Element browser has been blurred
[6975:Main Thread]: D/Focus Remote browser deactivated
[7411:Main Thread]: D/Focus Window 0x7fce9aab92a0 Lowered [Currently: 0x7fce9aab92a0 0x7fce9aab92a0]
[7411:Main Thread]: D/Focus   Lowered Window: file:///tmp/test.html
[7411:Main Thread]: D/Focus   Active Window: file:///tmp/test.html
[7411:Main Thread]: D/Focus <<Blur begin>>
[7411:Main Thread]: D/Focus Element input has been blurred
[7411:Main Thread]: D/Focus Update Caret: 0 1
[6975:Main Thread]: D/Focus Window 0x7f5e7b0792a0 Raised [Currently: (nil) (nil)]
[6975:Main Thread]: D/Focus   Raised Window: 0x7f5e7b0792a0 chrome://browser/content/browser.xul
[6975:Main Thread]: D/Focus <<Focus begin>>
[6975:Main Thread]: D/Focus Element browser has been focused
[6975:Main Thread]: D/Focus  from window
[6975:Main Thread]: D/Focus  [Newdoc: 1 FocusChanged: 0 Raised: 1 Flags: 0]
[6975:Main Thread]: D/Focus Remote browser activated
[6975:Main Thread]: D/Focus Update Caret: 0 1
[7411:Main Thread]: D/Focus Window 0x7fce9aab92a0 Raised [Currently: (nil) (nil)]
[7411:Main Thread]: D/Focus   Raised Window: 0x7fce9aab92a0 file:///tmp/test.html
[7411:Main Thread]: D/Focus <<Focus begin>>
[7411:Main Thread]: D/Focus Element input has been focused
[7411:Main Thread]: D/Focus  from html
[7411:Main Thread]: D/Focus  [Newdoc: 1 FocusChanged: 0 Raised: 0 Flags: 0]
[7411:Main Thread]: D/Focus Update Caret: 0 1

Comment 2

[Daniel Holbert [:dholbert]]

On Ubuntu 17.10, I get logging like the "normal" output, regardless of whether the password field is involved. (16 lines of output, with no parent-process-PID lines.)

Comment 3

[Daniel Holbert [:dholbert]]

I'm guessing this is due to some change between Gnome versions 3.26 and 3.28.  (Ubuntu 17.10 has the former version; 18.04 has the latter).  I don't see anything obviously related in the 3.28 release notes at https://help.gnome.org/misc/release-notes/3.28/ though...

Comment 4

[Daniel Holbert [:dholbert]]

Neil & karl, I think you're the expert folks on focus-handling & GTK (respectively) - any thoughts here on what I could do to debug this or investigate further?

Note that you can see the backtrace of the problematic "WindowLowered" call in my perf-html profile:
  https://perfht.ml/2GTdgE1
That just chains up to GTK functions, though ("gtk_widget_send_focus_change") with no obvious reason for why GTK decided we needed to be lowered, so I'm not sure where to go from there to find out what's cuasing this.

Comment 5

[Karl Tomlinson (:karlt)]

I'd guess WindowLowered implies that something is taking focus away from the browser window.
OnContainerFocusOutEvent in MOZ_LOG=WidgetFocus:4 would confirm that.

The "something" I'd guess is either an input method or accessibility.
Perhaps it is a virtual keyboard implemented via one of those.

Input methods can be disabled by GTK_IM_MODULE=gtk-im-context-simple.
I don't know how to disable accessibility hooks.

Comment 6

[Karl Tomlinson (:karlt)]

ni? Chris in case he has some ideas.

Comment 7

[Karl Tomlinson (:karlt)]

(In reply to Karl Tomlinson (:karlt) from comment #5)
> I'd guess WindowLowered implies that something is taking focus away from the
> browser window.
> OnContainerFocusOutEvent in MOZ_LOG=WidgetFocus:4 would confirm that.

No need for that as the perf-html profile indicates that function.

Are you able to install libgtk debug symbols to see if you can get a better stack trace, please?
Some of functions make sense, but they are all exported symbols, and so I suspect it is just returning the nearest exported symbol.

Comment 8

[Daniel Holbert [:dholbert]]

I already had "libgtk-3-dev" installed. I can't find any packages whose names include both "libgtk" and "dbg" (or "debug" or "sym"). I tried installing libgnomeui-0-dbg, but that doesn't seem to help.  So I'm not sure what the best route is to a better stack trace -- sorry. :-/

I did notice one other clue, though: the first time I focus the password field on the bugzilla-hosted version of the testcase (using Nightly), I see the following warning logged to my terminal (after all of the Focus logging):

(/home/dholbert/programs/firefox-nightly/firefox:13820): dconf-WARNING **: 11:03:07.900: Unable to open /var/lib/snapd/desktop/dconf/profile/user: Permission denied

The PID there (13820) is my content process, and it's being blocked by our sandbox (https://wiki.mozilla.org/Security/Sandbox ).  I only see this message if security.sandbox.content.level is 3 or higher (2 doesn't trigger it).

So: it seems like our content process is trying (and failing) to read some config file, specifically when the input type="password" field is focused... That's a bit mysterious.

Comment 9

[Daniel Holbert [:dholbert]]

(I also see comment 8's "dconf-WARNING" in Ubuntu 17.10, where the rest of this bug doesn't reproduce, FWIW.  So that message isn't directly correlated with things going wrong. But it might be a signal about what's happening under the hood that interacts poorly with 18.04...)

Comment 10

[Daniel Holbert [:dholbert]]

I'm currently suspecting this is due to some shenanigans with autocomplete and/or the login manager...

Comment 8's "dconf-WARNING" message comes from LoginManagerContent.jsm instantiating a "Services.intl.DateTimeFormat" object, here:
https://dxr.mozilla.org/mozilla-central/rev/071ee904485e21e19ca08456d32bce6825b77a26/toolkit/components/passwordmgr/LoginManagerContent.jsm#1450
...which under the hood makes us call OSPreferences::ReadDateTimePattern, which calls HourCycle(), which calls "g_object_new":
https://dxr.mozilla.org/mozilla-central/rev/071ee904485e21e19ca08456d32bce6825b77a26/intl/locale/gtk/OSPreferences_gtk.cpp#99
...and several stack-levels down, that calls "g_type_create_instance" which calls into libdconfsettings.so which tries to open a number of dconf-related files, including /usr/share/dconf/profile/user and /var/lib/snapd/desktop/dconf/profile/user .

I don't think that file-open is directly responsible for the problems here, but it was a good hint that we have some autocomplete code running at field-focus time that differs between password vs. non-password inputs.

Comment 11

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

(In reply to Daniel Holbert [:dholbert] (away 4/24 - 5/11) from comment #8)
> (/home/dholbert/programs/firefox-nightly/firefox:13820): dconf-WARNING **:
> 11:03:07.900: Unable to open /var/lib/snapd/desktop/dconf/profile/user:
> Permission denied
> 
> The PID there (13820) is my content process, and it's being blocked by our
> sandbox (https://wiki.mozilla.org/Security/Sandbox ).  I only see this
> message if security.sandbox.content.level is 3 or higher (2 doesn't trigger
> it).
> 
> So: it seems like our content process is trying (and failing) to read some
> config file, specifically when the input type="password" field is focused...
> That's a bit mysterious.

I think that's the same file whose role was analyzed in bug 1321134 comment #5 and following comments.  In that case the error is harmless; it just means it can't cache the preferences and reparses the storage every time.

And in theory we're allowing it, but if memory serves, there are a few layers of configurability around where it's located and we might be assuming defaults that Snap changes.

Comment 12

[Daniel Holbert [:dholbert]]

(In reply to Jed Davis [:jld] (⏰UTC-6) from comment #11)
> I think that's the same file whose role was analyzed in bug 1321134 comment
> #5 and following comments.  In that case the error is harmless; it just
> means it can't cache the preferences and reparses the storage every time.

(I think you're right, yeah.  This autocomplete-related stuff may've been a red herring; I tried disabling autocomplete by adding autocomplete="false" to the testcase and also by manually replacing the "StartControllingInput" call in nsFormFillController.cpp with a simple "return", but that didn't help with this bug's focus-loss issues.)

(In reply to Karl Tomlinson (:karlt) from comment #5)
> I'd guess WindowLowered implies that something is taking focus away from the
> browser window.
> The "something" I'd guess is either an input method or accessibility.
[...]
> 
> Input methods can be disabled by GTK_IM_MODULE=gtk-im-context-simple.


Oh! I only just saw this. I can confirm that if I run with  GTK_IM_MODULE=gtk-im-context-simple , then I get EXPECTED RESULTS here and on bug 1451418!  So this is totally it -- this must be a GTK input-method thing of some sort.

Comment 13

[Karl Tomlinson (:karlt)]

Attachment: X11 active window recording program

This may be helpful to detect which client/window is receiving focus, assuming the window manager is changing the active window.

The client id in the first column corresponds to the res_base field in output from xrestop -b -m 1.

The program provides some logging when run with no arguments.  Passing a client id as an argument provides extra logging for that client, but I'm guessing that is not necessary.

Comment 14

[Daniel Holbert [:dholbert]]

Here's the relevant output from that program, when I tab into the <input type='password'> field:
> 0x00e00000 FocusOut 0x00e00a24 NonlinearVirtual Grab
> 0x00e00000 FocusIn 0x00e00a24 NonlinearVirtual Ungrab

Comment 15

[Daniel Holbert [:dholbert]]

Yikes, Bug 1455047 is a significantly more serious manifestation of this -- it prevents users from logging in (and signing up) at Reddit.  I suspect other sites will be affected, too.

That makes this a significantly more serious issue.  karlt, I suspect you're in the best position to further diagnose this & come up with a solution -- any chance you can install Ubuntu 18.04 (either on a machine or a VM) to take a look here?  I really hope we can have some sort of a plan here before that upgrade is shipped (next week April 26th) and our Ubuntu users start updating their systems...

Comment 16

[Daniel Holbert [:dholbert]]

(I could try to look into this further, too, though I'm not as familiar with GTK internals or focus handling so I don't really know what I'm looking for, and more importantly, I'll be largely AFK on vacation in a couple days. :( Sorry to not be more helpful.)

Comment 17

[Karl Tomlinson (:karlt)]

Daniel, would you mind filing an issue on launchpad against ibus, please?

I'm hoping it will be helpful to get ibus people looking at this and to understand why ibus grabs the keyboard and if there is any way we can prevent that from happening.

Comment 18

[Karl Tomlinson (:karlt)]

Masayuki-san, wondering whether you know anything about this or the appropriate people to include?

Comment 19

[Karl Tomlinson (:karlt)]

Sorry, I'm not likely to be able to spend much time on this, and will not be available for the next couple of days.

Comment 20

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

Sound like that this is similar to bug 1292830. When I investigated the stack trace, they patched their GDK to move focus temporarily when Alt is pressed (perhaps, for hacky combination with Unity). I guess that similar odd focus changing API calls is added for password fields.

Comment 21

[Daniel Holbert [:dholbert]]

Thanks. I've now reported this upstream in launchpad against ibus: https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1765304

Comment 22

[Daniel Holbert [:dholbert]]

I also filed a github issue on the ibus project itself ( https://github.com/ibus/ibus/issues/2002 ).

New information from that issue:
 - Fedora (versions 27 & 28-beta) are unaffected, even with the same version of ibus.
 - An ibus developer posted a link to a possibly-related Red Hat issue: https://bugzilla.redhat.com/show_bug.cgi?id=1552668
 - ...and he/she suggested that this might be fixed with a mutter or gnome-shell update (perhaps via the upstream bugfix that was associated with that Red Hat issue?)
 - ...and he/she also said this might be a bug in Firefox/mutter integration.
 - I posted asking for further clarification.

Comment 23

[Daniel Holbert [:dholbert]]

I'm about to disappear for a few weeks, but if anyone's able to run Ubuntu 18.04 and interested in pushing this forward in the near term, it sounds like the ibus maintainer's suggested next step is to try to build older ibus versions on Ubuntu 18.04: https://github.com/ibus/ibus/issues/2002#issuecomment-383782378 )

Comment 24

[Samuel Thibault]

You may want to try to use the patch which is getting commited to gtk, see 

https://gitlab.gnome.org/sthibaul/gtk/pipelines/10153

It notably avoids deactivating/activating widgets on mere FocusIn(NotifyGrab)/FocusOut(NotifyUngrab), so I guess it could just fix the issue altogether.

Comment 25

[Karl Tomlinson (:karlt)]

Yes, I expect so.  Thanks, Samuel!

Comment 27

[Robert Strube]

I can confirm that this problem still exists for FF 61.0.1 running on Ubuntu 18.04.1.  It seems to only affect certain websites.  When you click on the password field, the field immediately blurs.
This makes it impossible to enter in a password.

Here's an example of the bug in action:

1.Navigate to: http://www.movescount.com/

2. Click the "Sign In" button.

3. Try to enter a password, you'll see that something is happening client side that very quickly blurs the password field. If you're quick you can maybe enter in a single letter, but that's about it. 

I can also confirm that this bug does not exist on FF 61.0.1 running on Windows.  So it seems to be a Linux or at least Ubuntu 18.04 specific issue.

Comment 28

[Dennis Schubert [:denschub]]

dholbert, we have received some reports that this is breaking login forms on sites like booking.com, prestocard.ca, and blood.ca, so this just turned into a somewhat serious webcompat issue! Do you have any idea on how we could get this fixed?

Comment 29

[Daniel Holbert [:dholbert]]

(In reply to Dennis Schubert [:denschub] from comment #28)
> Do you have any idea on how we
> could get this fixed?

I wish I knew of something easy we could do on our end. :-/

My investigation with karlt earlier basically discovered that this was an issue caused by the external "ibus" tool being overzealous (and making the OS literally steal input-focus away from Firefox and then return it), due to a change in gnome3.

Our best hope is for ibus/gnome to ship an update. (I'm not sure there's anything at all we can do on Firefox end, besides somehow disabling or changing our ibus integration, which would be risky & would likely break some input methods, i.e. the ability to enter e.g. Chinese characters.)

Good news is that the ibus maintainer (https://github.com/fujiwarat ) has posted a Gnome patch that's awaiting review[1], and also an patch to work around this in the ibus tool itself [2]. So I think we want do do what we can to encourage those patches to be merged / shipped in system updates.

[1] https://gitlab.gnome.org/GNOME/gnome-shell/issues/391
[2] https://github.com/fujiwarat/ibus/commit/ca8ce8ba969ef679cf18ddf2872d31426b21a2db

Comment 33

[Daniel Holbert [:dholbert]]

This has been fixed upstream in gnome-shell, and Ubuntu 18.04 has a package update going out shortly (currently in bionic-proposed) with the fix (verified to fix the issue by multiple users including me).

See https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1765304/comments/47 through https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1765304/comments/51 for more.

Comment 34

[Daniel Holbert [:dholbert]]

So I guess that means we can close this as "INVALID" for the purposes of bugzilla.mozilla.org, since it was a bug present in (& fixed in) an external piece of software, not in Firefox.   And there's no value in keeping this bug report open for discussion of diagnosis/options/workarounds now that there's a fix already on the way.

Hooray!

Comment 35

[Dennis Schubert [:denschub]]

Thank you for following through! :)