#chatline triggers autofill

[gpotter2]

Website Problem

• [x] Clearing cache and refreshing the page (On Firefox, press Ctrl+F5. On Chrome, press F12, then right click the refresh button and click "Empty Cache and Hard Reload")
• [x] Disabling all browser extensions
• [x] Using a clean channel with no customizations

Description of the Problem

• What happens?

On certain platforms/browsers, the #chatline element is detected as a "Name Field", therefore autofills with stores data. That's reproducible 100% of the time on Safari on IOS

(note: other IOS browsers such as Firefox for IOS won't trigger the issue)

• What do you expect to happen instead?

Not to do that

System Information

• Operating System: iOS
• Web Browser: Safari for IOS

Additional Data

I've done some researchs, while trying to fix this with JS at first. They are many scripts available online such as https://github.com/terrylinooo/jquery.disableAutoFill (which doesn't work, at least when I run it). It is also recommanded to add autocomplete="off" but that didn't do the trick either.

Safari most likely tries to match the fields with their IDs/Names. If you call a field "name", it will trigger autofill. It's probably something like that. I'm not sure how the input field is defined on your end, but maybe trying to rename the form/field/... could fix that.

Thanks a lot for this amazing project !

[calzoneman]

Interestingly, this is not the first time a buggy user-agent has caused users grief with trying to autofill fields that are not meant to be autofilled.

The full HTML tag for the chat input element is:

<input class="form-control" id="chatline" maxlength="320" style="" type="text">

Which does not contain a form name attribute, is not nested inside a <form>, and does not contain the word "name" anywhere in it, so I'm not sure what iOS might be matching.

Safari not respecting autocomplete="off" appears to be a years old issue with no resolution as far as I can tell: https://discussions.apple.com/thread/5940980?answerId=25080203022.

I'd be curious if you're specifically having an issue with cytu.be, i.e., at some point Safari remembered cytu.be as an "autocompletable" website and now it's suggesting it on multiple input fields. I'd be curious if you have the same issue:

• In a private browsing session
• On https://beta.synchtube.me/r/test (which is a different domain from cytu.be)

[gpotter2]

Thanks for the follow-up:

Test server (remains)

(Note: the hidden fields are email addresses)

Private browsing (apparently is gone)

However this could also only mean that AutoFill is always disabled in private browsing :/ I will check other websites

[gpotter2]

I just tried another website with/without private browsing (the first register page I could find :smile:)

AutoFill appears in both cases

[calzoneman]

But it doesn't show for the guest name login field? I wonder if it's because the chatline starts as hidden and becomes visible once the user is logged in, maybe that could be triggering Safari to pop up an autofill? I don't really have a recent iOS device handy to test with.

Anyways it seems like this is likely an issue with Safari -- if your suggested solution of autocomplete="off" is not respected by Safari, and the input element already contains no references to common form fields like "name", I'm really at a loss of what would be in my power to do to work around this.

[Xaekai]

I would like to add that I, and several other users in my channel, also have this nuisance and have had it for several months. I use Chromium on Linux. I have tried several remedies, including adding the disabling autocomplete parameter, but it does nothing. However in my case it is intermittent. When I first load the page it does not autofill. But after some unknown trigger it will pop up suggestions from many different autofill fields and it doesn't go away for the rest of the session.

I did not open an issue here about it because I believe it may be an upstream bug exposed recently in some code shared by Webkit and Blink, as both were forks of KDE's webengine.

[Xaekai]

Took a few hours, but indeed, it happened today.

[calzoneman]

It would be worth investigating if any of the javascript-driven .focus() calls to that element could be causing the browser to suddenly think the website is asking you to fill in that form field.

[gpotter2]

I tried the focus tricks (if that's what you mean) already after seeing it on Stackoverflow, where something is first read only, then became clickable on focus.

It didn't work on my end :/

But yeah, it could be linked to focus. I'll try to investigate

[calzoneman]

Does anyone have more concrete evidence of how this occurs?

[Xaekai]

No idea, but it's definitely still an issue for my users

[calzoneman]

It would be helpful if someone who is experiencing the issue could provide the diagnosis described by this StackOverflow answer

The OP's problem may have been solved (or may have come back again in recent updates!) but as of early 2019, you can diagnose some of these problems by setting the show-autofill-type-predictions flag in chrome://flags, restarting Chrome, then looking at the title (tooltip text) for the input in question. It will tell you what information is being used to guess the "type" of field, and what kind of saved data should be used to populate it.

[gpotter2]

EDIT:

However I'm starting to think that the issue relies in the (hidden) field right after the chat line: https://github.com/calzoneman/sync/blob/4c9e85b293d4f6149e53db843885b36275665890/templates/channel.pug#L50

The field contains "login" in its name, which I think some browsers try to fill, dumbly assuming it's a login form.

Demo on iOS:

On iOS, "Login using my credentials" appears to fill this field when not logged in:

and try to fill it anyways, even when it's a hidden field (therefore creating the issue) when logged in:

It's safe to assume a dumb parser detects the login field, and tries to fill the hidden field. Maybe it then also tries to fill the other fields near.

It could be worth a shot removing either the "Login" mention: simply "Guest name:" or similar workarounds :/

[calzoneman]

However I'm starting to think that the issue relies in the (hidden) field right after the chat line:

Plausible, but in this scenario I would imagine it's the element ID guestname or the placeholder text Name that is triggering autofill on that field. I wouldn't necessarily consider it a bug for autofill to suggest a guest name since it is legitimately a username field (although it's not particularly helpful if the browser suggests your registered username in that field instead of the login box at the top, when you are not logged in).

To me the buggy behavior here is trying to fill in addresses, credit card numbers, or god knows what else into the chatline field which is why I'm curious how it's getting flagged.

I could add autocomplete="off", but browsers won't respect it (because think of the bad guys that might use this behavior to do bad things!). I could try various hacks such as renaming the field dynamically, but that breaks custom CSS. I could try randomly renaming labels to try to outwit the browser, but that sounds like an unwinnable game of whack a mole.

I kind of feel like this should be reported as a bug to the browser vendor -- vomiting personal information into random form fields on the internet doesn't seem like a desirable property for a program to have. They may have declared they won't respect autocomplete="off" but maybe they will at least be willing to tune their heuristics to avoid this kind of situation.

[calzoneman]

On a whim I was inspired to look at this again and I dug up this part of the Chromium source, which details the regexes used to match certain autocompletion types: https://github.com/chromium/chromium/blob/5010349367c9d74bf5946273c1ead4a29e61d18c/components/autofill/core/common/autofill_regex_constants.cc

There is other logic involved beyond matching the regex (credit card example), but this could be a starting point for why we're seeing this issue.

• Address: the element is called #chatline which is presumably matching "line"
• Credit cards: as pointed out previously in this issue, the input element following #chatline is #guestname; what could be happening here is Chromium's heuristics thinking that form field is the cardholder name field and then inferring that the chatline is the credit card number field
• Since the chat-related fields are not grouped within a <form>, it's possible Chromium is gaining clues from other input elements on the page

[calzoneman]

This is actually trivially reproducible:

1. Add a credit card to Chrome autofill (I entered a fake number for testing)
2. Enter "cc number" in the chat
3. Refresh the page

It appears Chrome treats the chat area as part of the same "form" as the chat input. This explains why users previously saw nondeterministic behavior: whether or not Chrome thinks the chat line is an input field of varying kinds (CC, address, etc.) depends on whether someone in recent chat has said something that matches one of the above regexes.

Given I can't control what users say in chat (and the regexes are rather broad), it looks like the solution is to try to nest the elements in such a way that Chrome doesn't think they are part of the same form.

[calzoneman]

Similar test case for "address"

[Xaekai]

Given I can't control what users say in chat (and the regexes are rather broad), it looks like the solution is to try to nest the elements in such a way that Chrome doesn't think they are part of the same form.

I think a much better solution would be calling whoever wrote the upstream code a dumbass.

[calzoneman]

I believe the above commit avoids the problem.

[calzoneman]

Hotpatched to cytu.be

[Xaekai]

So I'm guessing this is what broke my chanscript chatline commands system, haha.

[gpotter2]

Thanks a lot for the fix ❤️