New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 658987 link

Starred by 1 user
Status: Assigned
Owner:
dvadym@chromium.org
Cc:
hwi@chromium.org
sabineb@chromium.org
█ ainslie@chromium.org
ios-bugs@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: iOS
Pri: 3
Type: Bug



Sign in to add a comment

Password manager on iOS fails to fill if <input> is not owned by a <form>

Project Member Reported by zkoch@chromium.org, Oct 25 2016 
On some sites, when you go to log in, the autofill "chip" appears in the keyboard accessory view, but when you tap it, the keyboard closes but it doesn't fill anything in. This is consistently reproducible. 

Example URL:

https://secure.hulu.com/activate

Looking at https://secure.hulu.com/activate on iOS, it does not have a <form> around the <input> elements.

Comment 1 by vabr@chromium.org, Oct 25 2016

Labels: Hotlist-Polish
Status: Available (was: Untriaged)
Summary: Password manager on iOS fails to fill if <input> is not owned by a <form> (was: Password manager on iOS fails to fill on certain sites)
On desktop, https://secure.hulu.com/activate contains an iframe from https://auth.hulu.com/login.

On iOS, https://secure.hulu.com/activate contains the login form directly, and the <input> elements are not wrapped inside a <form>. That is the reason why Chrome on iOS cannot fill that form, even if it has credentials stored for https://secure.hulu.com/activate. Filling on https://auth.hulu.com/login works OK. Note that even if the secure.hulu... page did contain an ifram with auth.hulu... as on desktop, Chrome on iOS would still not be able to fill (bug 554927).

I am not sure why the suggestion appears in the keyboard accessory view, though, and could not reproduce that behaviour.

To fix this bug, we likely need to start supporting <input> elements outside of <form>. I will amend the description to point that out.

Comment 2 by vabr@chromium.org, Oct 25 2016

Description: Show this description

Comment 3 by vabr@chromium.org, Oct 25 2016 

I stand corrected that the barrysbootcamp.com case does have a <form> element. I filed  bug 659173  for that one, it seems that Chrome's injected scripts hit some cross-origin protection of the WebView.

Comment 4 by vabr@chromium.org, Oct 25 2016

Description: Show this description
Project Member

Comment 5 by sheriffbot@chromium.org, Oct 26 2017

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 6 by vabr@chromium.org, Oct 27 2017

Status: Available (was: Untriaged)
Project Member

Comment 7 by sheriffbot@chromium.org, Oct 29

Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 8 by pkl@chromium.org, Oct 29

Owner: dvadym@chromium.org
Status: Assigned (was: Untriaged)

Comment 9 by vabr@chromium.org, Nov 29

Cc: -vabr@chromium.org
vabr going hobby only -> reducing involvement.
Please contact me directly in urgent matters.
►

Sign in to add a comment