Not possible to remove "required" attribute
Reported by
jpsyjo...@gmail.com,
Mar 30 2016
|
|||||||
Issue descriptionChrome Version : 49.0.2623.110 (64-bit) on OS X El Capitan and Windows 7 URLs (if applicable) : https://jsfiddle.net/qhxLmu0p/ Other browsers tested: Add OK or FAIL, along with the version, after other browsers where you have tested this issue: Safari: OK Firefox: OK What steps will reproduce the problem? (1) Create input radio buttons in a form and add "required" attributes. (2) Remove required attributes using JavaScript. (3) Try to submit the form without checking any of the radio buttons. What is the expected result? Form should submit. What happens instead? Chromes insists that you click a radio button before submitting. Please provide any additional information below. Attach a screenshot if possible. See JSfiddle URL above for a reduced demo of the problem. This problem has appeared within the last 2 to 3 weeks in the standard channel of Chrome. Even hidden radio buttons (display:none;) are affected. Side note: The issue especially messes up any forms that dynamically show/hide input groups through JS. As soon as these groups contain required fields, they cannot be muted anymore. A severe problem for more elaborate forms. A workaround could not be found.
,
Mar 31 2016
The CSRF... error message is the expected behavior, it shows that the form was submitted and is a result of the JSFiddle environment. In our tests this happens in Firefox and IE but NOT in Chrome. Instead the browser validation acts as if the radio buttons would still be "required". See the attached screenshot. This issue has also been confirmed by a member of the jQuery bug tracking team (we first reported there as we thought it would be a jQuery issue). See here: https://github.com/jquery/jquery/issues/3027 I am amazed that you cannot reproduce it. We have it since Chrome 49 on all sorts of systems (OS X, Win 7, Win 10) that all worked flawlessly with 48. Could you please check once more and make sure NOT to check any of the radio buttons before you submit? If you still get a different result, I will be happy to create a video cast of the problem. Here is the better fiddle with a bit of JS in the form action (instead of a simple "#"), so it responds gracefully after a successful form submission: https://jsfiddle.net/h71r5h4k/
,
Mar 31 2016
Thank you for providing more feedback. Adding requester "msrchandra@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 11 2016
Verified the issue by navigating to the URL provided in Comment# 2 in Chrome# 49.0.2623.112 and Latest Canary# 51.0.2705. Clicking on either YES or NO, able to submit the form successfully. Seeing the same behavior on Firefox also. @jpsyjoe63 -- Could you please let us know if I have missed anything. Thanks in Advance.
,
Apr 11 2016
It's not about clicking the "Yes" or "No" it's about not being able to remove the "required" state of the field with javascript after rendering. So to reproduce: try to submit the form without clicking the radio field as this one should not be required, but in fact is still blocking the submission.
,
Apr 11 2016
As said in Comment 5 and in my response in Comment 2: "...make sure NOT to check any of the radio buttons before you submit!" This is about the "required" state. Submission WITHOUT yes or no selection must be possible.
,
Apr 11 2016
Thank you for providing more feedback. Adding requester "msrchandra@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 22 2016
,
Apr 25 2016
@jpsyjoe63 -- As already mentioned in Comment#1, submitting the form without checking any raido buttons is displaying the same error message, "CSRF verification failed. Request aborted." Verified on Latest Stable# 50.0.2661.87 and observed the same behavior. Note: Seeing the same behavior on Firefox also. Thank You.
,
Apr 25 2016
Hi MSRCHANDRA, you are correct. The problem has obviously been RESOLVED with version 50. I rechecked with old and new versions of Chrome stable and the issue definitely appears with 49.0.2623.110 but does NOT happen with 50.0.2661.86. So it can be marked as resolved. Thanks for staying with us on this matter!
,
Apr 25 2016
@msrchandra -- Report was started 1 month ago based on Chrome Version: 49.0 as stated. So if you test it with an updated version it is of course possible that the issue has been fixed in the meantime. Is fixed now in v50 but was present in v49.
,
Apr 25 2016
Thanks for the update, based on the same in comment#11, closing the issue. Thank you! |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by msrchandra@chromium.org
, Mar 31 2016Labels: Needs-Feedback