Skip to content
This repository has been archived by the owner on Oct 15, 2024. It is now read-only.

Chrome Autofill issues #926

Closed
fmeum opened this issue Jul 9, 2020 · 30 comments · Fixed by #1338
Closed

Chrome Autofill issues #926

fmeum opened this issue Jul 9, 2020 · 30 comments · Fixed by #1338
Assignees
Labels
A-autofill Area: Autofill C-tracking-issue Category: Tracking issue for a proposal or a category of bugs S-blocked Status: marked as blocked ❌ on something else such as a RFC or other implementation work.

Comments

@fmeum
Copy link
Member

fmeum commented Jul 9, 2020

This is meant as a tracking bug for known issues with Autofill in Chrome (supported as of Android P).

  1. Autofill stops working until Chrome is restarted (observable on Android Q+)

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 regex chrome.*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.0

Temporary 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.

  1. Autofill popups don't show on some page loads, but do on others (observable on Android P+)

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.0

Workaround: Implemented in #921, can be enabled from the settings via "Improve reliability in Chrome". Tap the "Tab view" button and reselect the current tab.

  1. Autofill stops working until Chrome is restarted (observable on Android P+)

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.0
Permanent 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.

  1. Autofill cannot save unmasked password if the password field is masked

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 enabled

  1. Chrome starts lagging on large pages when Autofill is enabled

When 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.0

@fmeum fmeum added the bug label Jul 9, 2020
@fmeum fmeum self-assigned this Jul 9, 2020
@fmeum fmeum pinned this issue Jul 9, 2020
@fmeum
Copy link
Member Author

fmeum commented Jul 14, 2020

Update: The fix for 2. has passed code review: https://chromium-review.googlesource.com/c/chromium/src/+/2288852, which obsoletes the workaround.

@fmeum
Copy link
Member Author

fmeum commented Jul 15, 2020

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.

@fmeum
Copy link
Member Author

fmeum commented Jul 15, 2020

This gets weirder by the minute: I found a workaround for 2 as well, no idea why it works though.

@fmeum
Copy link
Member Author

fmeum commented Jul 15, 2020

@msfjarvis Could you verify whether these workarounds work for you when Autofill breaks in Chrome?

@msfjarvis
Copy link
Member

@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.

@msfjarvis
Copy link
Member

No dice on Chrome Canary, even with Canary Webview.

@fmeum
Copy link
Member Author

fmeum commented Jul 15, 2020

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...

@msfjarvis
Copy link
Member

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...

@fmeum
Copy link
Member Author

fmeum commented Jul 16, 2020

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...

@msfjarvis
Copy link
Member

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 👍

@msfjarvis
Copy link
Member

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.

@fmeum
Copy link
Member Author

fmeum commented Aug 30, 2020

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.

@msfjarvis
Copy link
Member

https://chromium.googlesource.com/chromium/src.git/+/444aad9599a465e3db4c52b3331c5c286818e8bc

Issue 1 should be fixed in the next Canary build 🎉

@msfjarvis
Copy link
Member

v87.0.4268.0 is supposed to have shipped with the commit but I still need to use the workaround to make Autofill work 🤔

@fmeum
Copy link
Member Author

fmeum commented Sep 19, 2020

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?

@fmeum
Copy link
Member Author

fmeum commented Sep 19, 2020

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...

@msfjarvis
Copy link
Member

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?

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.

@msfjarvis
Copy link
Member

msfjarvis commented Sep 21, 2020

Got today's update, everything appears to work perfectly now Autofill does, but the browser itself appears to crash still, just less frequently. Gonna hold off on the promotion from flaky to supported until that's been gone at least a week.

@fmeum
Copy link
Member Author

fmeum commented Sep 22, 2020

Got today's update, everything appears to work perfectly now Autofill does, but the browser itself appears to crash still, just less frequently. Gonna hold off on the promotion from flaky to supported until that's been gone at least a week.

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.

@fmeum
Copy link
Member Author

fmeum commented Sep 22, 2020

The crashes are gone, but Autofill is misbehaving again. I will investigate, it does appear as if the fix doesn't work.

@fmeum fmeum removed the blocked label Sep 22, 2020
@fmeum
Copy link
Member Author

fmeum commented Sep 24, 2020

I ended up finding a permanent workaround to the first issue: The AugmentedAutofillService that is behind the breakage is not a system app, but a regular app that goes under the name "Device Personalization Service". I disabled it and immediately enjoyed flawless Autofill in Chrome. However, disabling it means losing access to certain clipboard recommendations.

@msfjarvis
Copy link
Member

I ended up finding a permanent workaround to the first issue: The AugmentedAutofillService that is behind the breakage is not a system app, but a regular app that goes under the name "Device Personalization Service". I disabled it and immediately enjoyed flawless Autofill in Chrome. However, disabling it means losing access to certain clipboard recommendations.

Losing way more than clipboard suggestions, actually.

• Live Caption, which automatically captions media playing on your Pixel.
• Screen Attention, which prevents the screen from turning off if you are looking at it, without having to touch it.
• Improved Copy and Paste that makes it easier to move text from one app to another.
• App Predictions in the launcher, which suggest the app you may need next.
• Smart Actions in Notifications, which adds action buttons to notifications which let you see directions to a place, track a package, add a contact and more.
• Smart Text Selection across the system, which makes it easier to select and act on text; for instance, you can long-click on an address to select it and tap to see directions to it.
• Linkifying of text in apps.

@fmeum
Copy link
Member Author

fmeum commented Sep 24, 2020

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).

@fmeum
Copy link
Member Author

fmeum commented Sep 25, 2020

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.

@msfjarvis msfjarvis unpinned this issue Oct 4, 2020
@msfjarvis msfjarvis pinned this issue Oct 4, 2020
@msfjarvis msfjarvis added A-autofill Area: Autofill C-tracking-issue Category: Tracking issue for a proposal or a category of bugs S-blocked Status: marked as blocked ❌ on something else such as a RFC or other implementation work. and removed type: bug labels Nov 5, 2020
@fmeum
Copy link
Member Author

fmeum commented Nov 15, 2020

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?

@msfjarvis
Copy link
Member

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.

@fmeum
Copy link
Member Author

fmeum commented Nov 22, 2020

I have added some more information to this issue. I'm hopeful that we'll get actual password save support with Chrome 89.

@fmeum
Copy link
Member Author

fmeum commented Dec 1, 2020

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.

@fmeum
Copy link
Member Author

fmeum commented Dec 16, 2020

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.

@fmeum
Copy link
Member Author

fmeum commented Jan 29, 2021

Fixed in Chrome Beta. We will finally be able to close this issue on March 3 in our time zones.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A-autofill Area: Autofill C-tracking-issue Category: Tracking issue for a proposal or a category of bugs S-blocked Status: marked as blocked ❌ on something else such as a RFC or other implementation work.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants