1635833 - First character gets selected then overwritten while typing in password entry box with autocomplete

Status: NEW

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

Description

[Adam Williamson]

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

Steps to reproduce:

I maintain the Fedora deployments of an automated testing tool called openQA: https://openqa.fedoraproject.org . We have a test that exercises the web UI for FreeIPA: https://www.freeipa.org (it's like Active Directory, only, you know, F/OSS and awesome). It joins a FreeIPA domain, then logs into the web UI as admin and creates a couple of users; a later step (if the test reaches it) involves logging into the web UI as one of the users and changing the user's password.

Throughout this process there are points at which the test has to enter passwords - to log into the web UI, to set a new password when creating a user, and to change the password. Firefox 76 updates showed up for Fedora yesterday, and when this test ran on them, it failed five out of six times (we have updates for Fedora 30, 31 and 32, and this test runs twice per update). Each failure seems to be due to a problem when typing a password.

What seems to happen is that, when openQA is entering the password, after it types the first character, that character somehow gets highlighted, and so the second character typed replaces it; so if we tried to type the password 'correcthorse', we wind up with 'orrecthorse'.

I have never seen this happen before Firefox 76 appeared. This test usually runs ten or more times a day and I've never seen it fail this way before; of course an automated test framework that types into VMs is inherently slightly flaky, and we do occasionally have flakes where typing something just went slightly wrong for some reason, but it's usually quite rare, I'd say the typical failure rate would be 1 in 100 or so, not 5 out of 6. And I've never seen this specific 'first character typed gets highlighted then overwritten' failure path before, when we do get a flake it's usually just that a keypress is missed or repeated.

More technical details: openQA works by running a qemu-kvm VM and having the test runner connect to it via VNC and pass keyboard and mouse inputs that way. In this test, we run Firefox directly on top of an X server as root (don't do this at home, kids!) by running startx /usr/bin/firefox -width 1024 -height 768. There is no Mozilla user account or master password or anything involved. Firefox navigates to the affected password entry fields by pressing 'tab'. In most of the failures, the bug happened on a FreeIPA 'Verify password' field in the 'Add User' or 'Reset password' dialogs, but one time it happened in the Cockpit - https://cockpit-project.org/ - Join Domain dialog, when entering the domain admin password (I forgot, the test enrols to the FreeIPA domain using Cockpit). Both Cockpit and FreeIPA use the Patternfly UI library - https://www.patternfly.org/v4/ - which is itself based on Bootstrap, I believe.

Actual results:

Sometimes when typing a password, the first character is highlighted then overwritten by the second character.

Expected results:

Password should have been entered as typed.

Comment 1

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Matthew N. [:MattN]]

I guess it would be good to confirm that the problem still happens with signon.rememberSignons set to false in about:config but so far it doesn't sound like a password manager issue, more likely editor/GTK.

Comment 3

[Adam Williamson]

Will check that. Also, as you asked for the input details from chat, here:

The test runs in a VM and the test runner interacts with it via VNC, so it works much like a regular human running a qemu VM and connecting to it by VNC - to Firefox it should look more or less exactly like a human at a keyboard. In case it's important, the exact code for the VNC stuff is https://github.com/os-autoinst/os-autoinst/blob/master/consoles/vnc_base.pm#L98 and https://github.com/os-autoinst/os-autoinst/blob/master/consoles/VNC.pm#L719 ; basically it splits a string into individual keypresses and does 'send key down; wait a bit; send key up' for each one in turn.

The test modules where I've seen it fail all do more or less this: on an affected page, type stuff in one or more other boxes (the bug has not yet happened anywhere but a password field, although these tests do a lot of typing in other fields in Firefox), then hit tab a known number of times to reach a password field, wait a second or so, and start typing the password. In most cases we're doing password creation or change, so there are two password boxes - an initial entry box, and a confirmation box - so usually we then hit 'tab' again, wait a second again, and enter the same password in the second box. Usually the test fails because the bug happens on one box but not the other, so the two passwords don't match. But as mentioned there was one case where it failed just on a login screen, with only one password entry box.

Comment 4

[Adam Williamson]

oh, speed of typing doesn't seem to be relevant. We can type at a whole range of speeds in openQA; usually these tests use a convenience function called type_safely which would result in a minimum 2 second wait between hitting tab and starting to type the password, and a fairly slow typing speed. I tested switching to our type_very_safely, which has a minimum 5 second wait between hitting tab and starting to type the password and a really slow typing speed, but it didn't help, we still commonly hit the bug.

Comment 5

[Adam Williamson]

So I tweaked the tests so we set the OfferToSaveLogins policy to false before we run Firefox - this is the same as setting signon.rememberSignons to false in about:config, I believe, it's just easier to do with our test setup. With that change, 5/5 tests passed. That was on the staging instance, I'll do it again on production, but if it holds it seems significant.

Comment 6

[Matthew N. [:MattN]]

This sounds like it could be related to bug 1451466 or https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1814551. Can you see if anything there helps? Maybe gnome-shell is used for openQA?

Comment 7

[Matthew N. [:MattN]]

(In reply to Adam Williamson from comment #5)

So I tweaked the tests so we set the OfferToSaveLogins policy to false before we run Firefox - this is the same as setting signon.rememberSignons to false in about:config, I believe, it's just easier to do with our test setup. With that change, 5/5 tests passed. That was on the staging instance, I'll do it again on production, but if it holds it seems significant.

Hmm… maybe password manager is somehow involved then… could you attach logs using instructions from https://wiki.mozilla.org/Toolkit:Password_Manager/Debugging

It would be useful to know if the problem is from password manager specifically or the autocomplete popup: Could you see if the problem happens with the pref signon.showAutoCompleteFooter set to false (with no logins saved for the base domain) and revert the policy change? There is no policy for this one.

Comment 8

[Matthew N. [:MattN]]

Testing with signon.passwordEditCapture.enabled set to false but the other signon.* stuff mentioned earlier back to defaults would also be useful since that feature is new in 76.

Comment 9

[Adam Williamson]

We're not using GNOME Shell in this particular path - as I mentioned, in this test path Firefox is run directly on an X server, there isn't even a window manager of any kind running. I don't believe ibus is installed, I can double check that.

I'll try and get the debug logs and test with that preference in a bit. Don't suppose there's some convenient way to set the pref from a console? It would be much easier than teaching openQA to open about:preferences and set it, but I can do that if I have to.

Comment 10

[Adam Williamson]

er, about:config I mean, obviously.

prod tests all passed with the OfferToSaveLogins change too, so that definitely seems like it works around the bug.

Comment 11

[Matthew N. [:MattN]]

Can you point this tool to an existing folder to use for the Firefox profile? If so you can set the values in a prefs.js file there.

Comment 12

[Adam Williamson]

yeah, just found that idea. I'm going to give it a whirl.

Comment 13

[Adam Williamson]

So it seems like signon.passwordEditCapture.enabled=false does not help, but signon.showAutoCompleteFooter does help. I'm running tests a few more times to double check, but I'm pretty sure.

Comment 14

[Adam Williamson]

er, signon.showAutoCompleteFooter=false helps, that is.

Comment 15

[Matthew N. [:MattN]]

Awesome, thank you so much for all your research today! We're close to getting to the bottom of this.

I think I understand why this started in Fx76 now… we started using heuristics to detect "new password" fields in order to offer password generation (bug 1595244; see the release notes). If you are able to watch the test run with VNC you would see the password generation option appear on the new password fields. It just so happens that disabling the autocomplete footer also disables password generation… I suspected the issue was autocomplete but didn't read comment 0 close enough to see the connection to "new password" fields.

Setting signon.generation.confidenceThreshold to the string (with quotes), not int, "-1" is the most direct way to workaround this as it disables our heuristics. So this explains why you are now seeing the problem on these specific fields now but I doubt this is the root of the problem as the password generation row itself shouldn't affect text input. If you added autocomplete=new-password to the "new password" <input> elements (as I would recommend to help password managers) then you would see the problem prior to Fx76, as early as Fx70. If you have an easy way of testing against Fx70 and adding autocomplete=new-password to one of the "new password" fields that just started showing the failure I'd be interested in knowing if the problem happened already then or whether this is a regression since then.

I suspect the root issue predates Fx76 and is related to the autocomplete input stealing focus or something like that. This would likely be a widget issue, not an editor one. You just happen to hit that now that autocomplete is appearing on the fields in question. I think this is a duplicate of bug 1565835, do you agree?

Thank again!

Comment 16

[Adam Williamson]

"If you are able to watch the test run with VNC you would see the password generation option appear on the new password fields."

I did catch the bug live a couple of times, and I didn't notice anything like that - I really just saw what I described, the test runner typing into the field and the first character getting highlighted and overwritten. I didn't see any kind of password generation UI appearing. I wonder if that's somehow part of the bug? Maybe it doesn't work in this slightly unusual environment, or something?

I can test signon.generation.confidenceThreshold tomorrow, I may be able to patch FreeIPA with autocomplete=new-password and try that with an older Firefox too, I'll give it a shot anyway. #1565835 does sound similar at least, yes.

Comment 17

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

:adamw, since this bug is a regression, could you fill (if possible) the regressed_by field?
For more information, please visit auto_nag documentation.

Comment 18

[Matthew N. [:MattN]]

Yeah, maybe the autocomplete popup doesn't render in this case but still steals focus or something.

I guess I can leave these bugs separate since bug 1565835 claims the autocomplete popup flashes quickly then disappears whereas you seem to not see that flash.

Comment 19

[Adam Williamson]

signon.generation.confidenceThreshold="-1" does indeed seem to do the trick as well.