Summary: | Add checks if setNeedsWillValidateCheck() and setNeedsValidityCheck() are called correctly | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Kent Tamura <tkent> | ||||
Component: | Forms | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | darin | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Bug Depends on: | 31716 | ||||||
Bug Blocks: | 31718 | ||||||
Attachments: |
|
Description
Kent Tamura
2010-02-14 05:11:09 PST
Created attachment 48721 [details]
Proposed patch
(In reply to comment #0) > > If we do cache a value I think it should be a single three-state concept: "will > > not validate", "valid", "invalid". Treating these as independent makes the code > > more complicated in places where they overlap. I know the DOM API for this > > treats them separately, but the style code would be much simpler if it used a > > single three-state concept. I couldn't apply the single three-state concept. According to the HTML5, the validity state should work even if willValidate is false. So the patch introduces two boolean members. Comment on attachment 48721 [details]
Proposed patch
in HTMLInputElement::setValue, it looks like
+ setNeedsValidityCheck();
can be lifted above the "inputType() == FILE" if-clause because its called on both branches.
This looks reasonable. I'm not an expert on validity checks, but this patch has been sitting around for a month and seems to prove the codebase.
Thank you for reviewing. (In reply to comment #3) > + setNeedsValidityCheck(); > > can be lifted above the "inputType() == FILE" if-clause because its called on > both branches. setNeedsValidityCehck() should be called after updating the value && before style recalc. So this code is the best. I'm adding a comment about it, and landing. |