Credit card autofill is offered, but fails, in the presence of unattached <input>s when there is no <form>
Reported by
chris.mo...@gmail.com,
Nov 12
|
|||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0 Steps to reproduce the problem: 1. Have a saved credit card 2. Open cc-autofill-stray-input-broken.html (attached, or at https://temp.chrismorgan.info/cc-autofill-stray-input-broken.html) 3. Select the card number field, and click on the autofill prompt. What is the expected behavior? Card number, name and expiry date should be filled. What went wrong? Although autofill was offered, the fields are not filled. Did this work before? Yes Not sure (but FastMail is hitting this, and it worked when first implemented) Chrome version: 70.0.3538.77 (Official Build) (64-bit) (cohort: Stable) Channel: stable OS Version: 10.0 Flash Version: This can be worked around by wrapping everything in <form>, or by removing stray form fields (fields without autocomplete="cc-*", I think). See the second and third attached files. The uploaded files are also served on my own HTTPS site (and I’m totally not going to steal your credit card details, but you should not submit the form or use real credit card details): https://temp.chrismorgan.info/cc-autofill-stray-input-broken.html https://temp.chrismorgan.info/cc-autofill-form-works.html https://temp.chrismorgan.info/cc-autofill-no-form-works.html This is affecting FastMail at present, though in the near future we’ll put the inputs into a form to work around this bug.
,
Nov 13
Able to reproduce the issue on Mac 10.13.6, Win-10 and Ubuntu 17.10 using chrome reported version #70.0.3538.77 but the same is not reproducible in the latest canary #72.0.3608.0. Reverse Bisect Information: ===================== Good build: 71.0.3544.0 Bad Build : 71.0.3543.0 Note: Unable to provide the change log by running per revision script due to the [Errno 2] No such file or directory. Also on running chromium bisect got all the good builds invoked. Hence, providing manual bisect (change log) from omahaproxy. Change Log URL: from omahaproxy https://chromium.googlesource.com/chromium/src/+log/71.0.3543.0..71.0.3544.0?pretty=fuller&n=10000 From the above change log suspecting below change Change-Id: Ifd8190148a0bf8dd3643da4016fb41dea3cc1ae3 Reviewed-on: https://chromium-review.googlesource.com/1208194 mathp@ - Could you please check and merge the fix to M-70 if it is a valid candidate. Note: The issue is marked with RVG. Hence, requesting mathp@ to please have a look into the issue. Also adding label RBS for M-70 as it seems to be a recent regression. Please feel free to remove the same if not appropriate. Issue is seen from M-60 builds but fixed on latest canary . Hence, not adding RegressedIn label. Thanks...!!
,
Nov 13
,
Nov 14
M71 stable promotion is going to happen very soon (where it works fine), so i do not think we need to consider it as M70 stable blocker.
,
Nov 14
,
Nov 14
,
Nov 14
I think this might be related to a bug I fixed recently. Tomorrow I'll check if my assumption is right and merge the fix to M-71 if it is.
,
Nov 14
It's too late for M-71, but it's fixed in M-72. Thanks for the report! |
|||||||||||||
►
Sign in to add a comment |
|||||||||||||
Comment 1 by swarnasree.mukkala@chromium.org
, Nov 13