Closed
Bug 1427542
Opened 6 years ago
Closed 6 years ago
reportValidity() permanently changes state of form (even if reset)
Categories
(Core :: DOM: Core & HTML, defect, P2)
Tracking
()
RESOLVED
FIXED
mozilla59
Tracking | Status | |
---|---|---|
firefox59 | --- | fixed |
People
(Reporter: sliploj, Assigned: jdai)
Details
Attachments
(2 files)
2.12 KB,
text/html
|
Details | |
4.71 KB,
patch
|
smaug
:
review+
|
Details | Diff | Splinter Review |
When reportValidity() is called on a form, any invalid fields get highlighted, as expected. However, if the form is later reset, whether by calling reset() or by clicking on an input of type "reset", any inputs that e.g. are marked required but are blank after reset will be marked as invalid (in most cases the entire form would be marked invalid since reset typically makes a form mostly/blank). The earlier call the reportValidity permanently changed the state of the form such that even resetting it doesn't clear validation status (even though I don't see anything in the spec about reportValidity being a call that should result in a permanent state change, but instead seems to be described as a one-off event). As far as I can tell, there's no way to clear the validation status of a form after calling reportValidity. This is in contrast to what happens if reportValidity() has not previously been called. If reportValidity() hasn't been called, but a field is marked invalid, resetting the form also clears the validation status for the fields (i.e. e.g. required fields that are blank as result of reset won't be marked invalid (until the user interacts with them again)). I've found that the lack of a way to clear the validation status of a form after calling reportValidity() is problematic e.g. if a form is supposed to get reused, because on re-use it already shows up with blank fields marked as invalid.
Comment 1•6 years ago
|
||
Reporter, could you kindly attach a minimal testcase showing the issue to this bug?
Flags: needinfo?(sliploj)
attaching HTML file with inline instructions for demonstrating the issue
Flags: needinfo?(sliploj)
for whatever it's worth, Edge and Internet Explorer don't have this problem; the issue doesn't apply in Chrome either since it doesn't use a border to highlight the fields
Comment 4•6 years ago
|
||
John, since you've been working on reportValidity (bug 1088761), could you take a look?
Flags: needinfo?(jdai)
Assignee | ||
Comment 5•6 years ago
|
||
Sure, I'll take a look. Keep NI for tracking.
Updated•6 years ago
|
Priority: -- → P2
Assignee | ||
Comment 6•6 years ago
|
||
I am able to reproduce this issue by using the testcase (attachment 8939383 [details]).
Assignee: nobody → jdai
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Assignee | ||
Comment 7•6 years ago
|
||
Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=c9e98af25a05a5ebfff5e222bc74e6893817564b&group_state=expanded&filter-tier=1
Flags: needinfo?(jdai)
Attachment #8940998 -
Flags: review?(bugs)
Updated•6 years ago
|
Attachment #8940998 -
Flags: review?(bugs) → review+
Assignee | ||
Updated•6 years ago
|
Keywords: checkin-needed
Pushed by jdai@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/f7567b2adc03 Fix reset a form can't clear -moz-ui-invalid after calling reportValidity. r=smaug
Keywords: checkin-needed
Comment 9•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/f7567b2adc03
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
status-firefox59:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•