Bug 92502

Summary: Fix removing invalid values from color input suggestions
Product: WebKit Reporter: Keishi Hattori <keishi>
Component: FormsAssignee: Keishi Hattori <keishi>
Status: RESOLVED FIXED    
Severity: Normal CC: dglazkov, mifenton, tkent, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch
none
Patch none

Keishi Hattori
Reported 2012-07-27 06:39:18 PDT
Removing invalid values from color input suggestions is broken.
Attachments
Patch (1.63 KB, patch)
2012-07-27 06:41 PDT, Keishi Hattori 		no flags
DetailsFormatted DiffDiff
Patch (4.82 KB, patch)
2012-07-27 07:28 PDT, Keishi Hattori 		no flags
DetailsFormatted DiffDiff
Patch (2.25 KB, patch)
2012-07-29 21:20 PDT, Keishi Hattori 		no flags
DetailsFormatted DiffDiff
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.
Keishi Hattori
Comment 1 2012-07-27 06:41:44 PDT
Created attachment 154931 [details] Patch
Kent Tamura
Comment 2 2012-07-27 06:49:23 PDT
Comment on attachment 154931 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=154931&action=review > Source/WebCore/html/ColorInputType.cpp:229 > - if (!element()->isValidValue(option->value())) > + if (!isValidColorString(option->value())) I think we should fix HTMLInputElement::isValidValue() in this case. isValidValue() exists for this purpose.
Keishi Hattori
Comment 3 2012-07-27 07:01:37 PDT
I shouldn't be returning true for typeMismatch etc., so do I need to add a method to InputType and check that in HTMLInputElement::isValidValue()?
Keishi Hattori
Comment 4 2012-07-27 07:28:59 PDT
Created attachment 154943 [details] Patch
Build Bot
Comment 5 2012-07-27 07:35:32 PDT
Comment on attachment 154943 [details] Patch Attachment 154943 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/13367530
WebKit Review Bot
Comment 6 2012-07-27 08:41:12 PDT
Comment on attachment 154943 [details] Patch Attachment 154943 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/13372493
Early Warning System Bot
Comment 7 2012-07-27 09:56:12 PDT
Comment on attachment 154943 [details] Patch Attachment 154943 [details] did not pass qt-ews (qt): Output: http://queues.webkit.org/results/13371564
Early Warning System Bot
Comment 8 2012-07-27 10:14:49 PDT
Comment on attachment 154943 [details] Patch Attachment 154943 [details] did not pass qt-wk2-ews (qt): Output: http://queues.webkit.org/results/13371566
Gyuyoung Kim
Comment 9 2012-07-27 10:47:04 PDT
Comment on attachment 154943 [details] Patch Attachment 154943 [details] did not pass efl-ews (efl): Output: http://queues.webkit.org/results/13376570
Darin Adler
Comment 10 2012-07-27 11:26:26 PDT
Comment on attachment 154943 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=154943&action=review > Source/WebCore/html/InputType.h:310 > + virtual bool isUsefulValue(const String& value) const; What does “useful value” mean in this context? How is “useful” different from “valid”? I find this terminology unclear.
Eric Seidel (no email)
Comment 11 2012-07-29 15:22:15 PDT
Comment on attachment 154943 [details] Patch The EWS bots are unhappy.
Kent Tamura
Comment 12 2012-07-29 18:34:14 PDT
Comment on attachment 154943 [details] Patch What you need to do is just to implement ColorInputType::typeMismatchFor(const String&). As you know, <input type=color> never cause typeMismatch validation failure because of the aggressive value sanitization. However implementing typeMismatch() is helpful for HTMLInputElement::isValidValue() because isValidValue() doesn't sanitize the specified string. NumberInputType does the same thing. If you feel implementing typeMismatchFor() is hacky, you had better update HTMLInputElement::isValidValue() so that it handles value sanitization correctly.
Keishi Hattori
Comment 13 2012-07-29 21:20:26 PDT
Created attachment 155204 [details] Patch
Keishi Hattori
Comment 14 2012-07-29 21:21:52 PDT
(In reply to comment #12) > (From update of attachment 154943 [details]) > What you need to do is just to implement ColorInputType::typeMismatchFor(const String&). > > As you know, <input type=color> never cause typeMismatch validation failure because of the aggressive value sanitization. However implementing typeMismatch() is helpful for HTMLInputElement::isValidValue() because isValidValue() doesn't sanitize the specified string. NumberInputType does the same thing. > > If you feel implementing typeMismatchFor() is hacky, you had better update HTMLInputElement::isValidValue() so that it handles value sanitization correctly. Ok, I implemented typeMismatchFor()
Kent Tamura
Comment 15 2012-07-29 21:30:19 PDT
Comment on attachment 155204 [details] Patch ok
WebKit Review Bot
Comment 16 2012-07-29 22:49:46 PDT
Comment on attachment 155204 [details] Patch Clearing flags on attachment: 155204 Committed r123997: <http://trac.webkit.org/changeset/123997>
WebKit Review Bot
Comment 17 2012-07-29 22:49:50 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.