-
-
Notifications
You must be signed in to change notification settings - Fork 270
Chrome Autofill issues #926
Comments
Update: The fix for 2. has passed code review: https://chromium-review.googlesource.com/c/chromium/src/+/2288852, which obsoletes the workaround. |
Good news: I found a workaround for 1, but it's something that users will not come up with unless we tell them about it. Bad news: The CL I submitted for 2 does not fully fix the issue in Chrome, although it did in Chromium. Will investigate more. |
This gets weirder by the minute: I found a workaround for 2 as well, no idea why it works though. |
@msfjarvis Could you verify whether these workarounds work for you when Autofill breaks in Chrome? |
Neither of them worked for me on Chrome stable. I'll try on Canary after lunch and let you know. |
No dice on Chrome Canary, even with Canary Webview. |
Could you record a video? It's really terrible how non-reproducible all of this is, I'm close to giving up... |
Began recording a video and the second workaround started working :/ this is all so stupid... |
My bad, issue 2 should finally be fixed, the fix was just not contained in yesterday's 86.0.4202.0 Canary release. It is contained in today's release 86.0.4204.0, so please try again with that one. How did I end up thinking that it was in 4202? Since source.chromium.org resets the tag on each search... |
Can confirm it is fixed on my Pixel running Android 11 and Samsung M30s running Android 10 👍 |
Current Chrome Canary build is pretty great with Autofill, I think this issue can be closed. I can't repro either problem on Version 87.0.4249.0. |
I can still repro issue 1 and it's actually quite annoying. Unfortunately the essential reviewer is lost in perf or otherwise unresponsive. I will keep at it, so let's leave this open for now. |
https://chromium.googlesource.com/chromium/src.git/+/444aad9599a465e3db4c52b3331c5c286818e8bc Issue 1 should be fixed in the next Canary build 🎉 |
v87.0.4268.0 is supposed to have shipped with the commit but I still need to use the workaround to make Autofill work 🤔 |
Could you send me logs with Autofill verbosity set to verbose in the developer settings? |
Autofill in the same version of Chrome Canary works really well for me, but the browser sometimes crashes on page loads. Hope that's not on us... |
Tried doing so but Chrome crashes every 5 seconds for me as well so I'm assuming that earlier I simply hadn't finished updating and that's why the workaround was needed. Gonna wait it out for the next canary and see if the crash is fixed. |
Got today's update, everything appears to work |
Agreed, let's wait for Chrome to become less crashy. As crashes function as a (terrible) workaround for issue 1, we won't be able to tell whether it works anyway. |
The crashes are gone, but Autofill is misbehaving again. I will investigate, it does appear as if the fix doesn't work. |
I ended up finding a permanent workaround to the first issue: The |
Losing way more than clipboard suggestions, actually.
|
That's unfortunate... I have contacted another one of the Android devs working on Autofill and am hoping that I'll get a response this time. When Chrome Canary stops crashing and should reveal that my fix is not working as intended, their input may be very helpful. I'm out of ideas otherwise (short of trying to push marking the URL bad important for Autofill again). |
Chrome Canary is no longer crashing, but for some reason the fix doesn't fix anything in Chrome. I have created a revert and will evaluate other options. |
We got Issue 1 fixed as of Chrome 89.0.4326.0. It shadowed another issue, but this one should only happen infrequently. I will investigate a bit more and see whether we can do something about it. @msfjarvis We've got all the time we need, but could you also confirm that Autofill works better on your end and that all failures are accompanied by log entries as indicated in Issue 3? |
I haven't been on Chrome Canary since the brief phase where it just crashed all the time. I just switched back, so it'll take a bit to confirm this. I'll report back as soon as I notice failures. |
I have added some more information to this issue. I'm hopeful that we'll get actual password save support with Chrome 89. |
The Autofill fill UI is working completely reliably for me on Chrome 89.0.4342.0, which is the current Canary release. Save support for passwords is currently in privacy review and will likely be merged soon. |
The fix for the accessibility issues has made it into 89.0.4356.0. While the performance could still be better, at least Chrome is usable on large pages now while Autofill is enabled. Now that all issues that I'm aware of are fixed, we'll just have to wait until the end of January 2021 and 89's promotion to Beta. By that time we can probably recommend switching to it in case of Autofill issues. |
Fixed in Chrome Beta. We will finally be able to close this issue on March 3 in our time zones. |
This is meant as a tracking bug for known issues with Autofill in Chrome (supported as of Android P).
This is likely caused by this bug in Android and can be confirmed by enabling verbose Autofill logging in developer options searching the output of
adb logcat
for occurences of the regexchrome.*forAugmentedAutofillOnly=true
.Fix:
I have filed an Android bug and a Chrome bug. Ideally, Chrome would work around this issue on all versions of Android by labelling their URL bar as important for Autofill.Fixed in Chrome 89.0.4326.0Temporary Workaround: Tap on the URL bar, then long-tap and select "Autofill". This resets the current session to not use augmented Autofill.
Permanent Workaround: Disable the app "Device Personalization Service" from its "App Info" tab.
This is caused by a design incompatibility between Android's implementation of the Autofill accessibility compat mode and Chrome's accessibility backend as explained here.
Fix:
I have filed a Chrome bug and a CL that fixes the underlying accessibility issue in Chromium.Fixed in Chrome 86.0.4204.0Workaround:
Implemented in #921, can be enabled from the settings via "Improve reliability in Chrome".Tap the "Tab view" button and reselect the current tab.This is caused by reaching the maximum number of allowed partitions in an Autofill session. If the URL bar is not detected as having been changed, navigating between tabs all plays out in a single Autofill session. This may not be an issue in practice since it requires 10 Autofill triggers in a row. Can be detected in the logs via the regex
because session \d+ reached maximum of
.Fix:
A CL that mostly works around this limitation is under review here.Fixed in Chrome 89.0.4342.0Permanent workaround: Increase the number of partitions via e.g.
adb shell settings put global autofill_max_partitions_size 100
.Temporary workaround: To get Autofill working in a tab when the maximum partition count has been reached, open the recent apps menu and return to Chrome. This will allow one more Autofill trigger.
As of Android O, Chrome respects the masking state of password fields when reporting their contents to Accessibility services.
Fix:
Chrome should report the unmasked password at least if there is not other Accessibility service than Autofill. This is the content of a Chrome CL.Fixed in Chrome 89.0.4346.0 if no Accessbility service is enabledWhen loading a large web page (e.g. basically anything on https://cs.chromium.org), Chrome becomes unresponsive for more than 10s of Autodill or an Accessibility service are enabled.
This is likely caused by a helper function that traverses the entire Accessibility tree twice on every event.
Fix:
A fix is being developed in this Chromium CL.Mostly fixed in Chrome 89.0.4356.0The text was updated successfully, but these errors were encountered: