Bug 96683 - Add min and max input field values to Chromium API
Summary: Add min and max input field values to Chromium API
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-09-13 12:39 PDT by Anthony Berent
Modified: 2013-04-09 17:07 PDT (History)
7 users (show)

See Also:


Attachments
Patch (5.14 KB, patch)
2012-09-13 12:49 PDT, Anthony Berent
no flags Details | Formatted Diff | Diff
Patch (5.93 KB, patch)
2012-09-13 14:17 PDT, Anthony Berent
no flags Details | Formatted Diff | Diff
Patch (5.95 KB, patch)
2012-09-13 15:25 PDT, Anthony Berent
tkent: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Anthony Berent 2012-09-13 12:39:43 PDT
Add min and max input field values to Chromium API
Comment 1 Anthony Berent 2012-09-13 12:49:08 PDT
Created attachment 163939 [details]
Patch
Comment 2 WebKit Review Bot 2012-09-13 12:54:30 PDT
Please wait for approval from abarth@webkit.org, dglazkov@chromium.org, fishd@chromium.org, jamesr@chromium.org or tkent@chromium.org before submitting, as this patch contains changes to the Chromium public API. See also https://trac.webkit.org/wiki/ChromiumWebKitAPI.
Comment 3 Anthony Berent 2012-09-13 13:58:28 PDT
These are needed by Chrome on Android to allow it to limit the range of, for example, dates when using Android native widgets and dialogs for input.
Comment 4 Anthony Berent 2012-09-13 14:17:38 PDT
Created attachment 163964 [details]
Patch
Comment 5 Darin Adler 2012-09-13 14:20:07 PDT
Comment on attachment 163964 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=163964&action=review

> Source/WebKit/chromium/src/WebTextInputInfo.cpp:45
> +        && min == min
> +        && max == max;

Missing the "other." prefix on both of these lines.

> Source/WebKit/chromium/src/WebViewImpl.cpp:2162
> +        if (input->isNumberField()
> +            || input->isRangeControl()
> +            || input->isDateField()
> +            || input->isDateTimeField()
> +            || input->isDateTimeLocalField()
> +            || input->isMonthField()
> +            || input->isWeekField()
> +            || input->isTimeField()) {
> +            info.min = input->minimum();
> +            info.max = input->maximum();

This long if statement is bad for maintenance of HTMLInputElement. We may add new types or decide not to use this style of boolean getter. Is there some reason you can’t just call minimum and maximum unconditionally?
Comment 6 Anthony Berent 2012-09-13 14:37:46 PDT
(In reply to comment #5)
> (From update of attachment 163964 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=163964&action=review
> 
> > Source/WebKit/chromium/src/WebTextInputInfo.cpp:45
> > +        && min == min
> > +        && max == max;
> 
> Missing the "other." prefix on both of these lines.

Agreed, will fix.

> 
> > Source/WebKit/chromium/src/WebViewImpl.cpp:2162
> > +        if (input->isNumberField()
> > +            || input->isRangeControl()
> > +            || input->isDateField()
> > +            || input->isDateTimeField()
> > +            || input->isDateTimeLocalField()
> > +            || input->isMonthField()
> > +            || input->isWeekField()
> > +            || input->isTimeField()) {
> > +            info.min = input->minimum();
> > +            info.max = input->maximum();
> 
> This long if statement is bad for maintenance of HTMLInputElement. We may add new types or decide not to use this style of boolean getter. Is there some reason you can’t just call minimum and maximum unconditionally?

There are comments in HTMLInputElement saying one should not call them for other types. As such it seemed the check was needed.

    // Returns the minimum value for type=date, number, or range.  Don't call this for other types.
    double minimum() const;
    // Returns the maximum value for type=date, number, or range.  Don't call this for other types.
    // This always returns a value which is >= minimum().
    double maximum() const;
Comment 7 Anthony Berent 2012-09-13 15:25:08 PDT
Created attachment 163982 [details]
Patch
Comment 8 Kent Tamura 2012-09-13 17:48:55 PDT
Comment on attachment 163982 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=163982&action=review

> Source/WebKit/chromium/ChangeLog:8
> +        Required to correctly bound values in native widgets used, for example, for date entry in Chrome on Android.

I'm not sure this should be done in WebTextInputInfo.  Can we obtain them from WebInputElement? Can we expose WebCore/platform/DateTimeChooser.h via WebKit API?

> Source/WebKit/chromium/public/WebTextInputInfo.h:61
> +    double min;
> +
> +    // The maximum value of the field (only meaningful for numbers, ranges,
> +    // and date or time based fields).
> +    double max;
> +

min and max should be initialized in the constructor.
Also, we should have "step" value.

> Source/WebKit/chromium/tests/WebViewTest.cpp:377
> +    EXPECT_EQ((double)1000*24*60*60, info.max);
> +    EXPECT_EQ((double)-1000*24*60*60*2, info.min);

Do not use C-style cast.  In this case, 1000.0 * 24 * 60 * 60 works without the cast.
Comment 9 yosin 2012-09-18 18:35:44 PDT
Comment on attachment 163982 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=163982&action=review

> Source/WebKit/chromium/src/WebViewImpl.cpp:2153
> +        if (input->isNumberField()

How about using HTMLInputElement::isSteppable() and HTMLInputElement::createStepRange()?
If we use them, we can write

if (input->isSteppable()) {
  const StepRange stepRange = input->createStepRange();
  info.min = stepRange.minimum();
  info.max = stepRange.maximum();
}

Note: HTMLInputElement::minimum() and maximum() call createStepRange().
Comment 10 Anthony Berent 2012-09-25 02:42:10 PDT
There is a plan to change how date and time are supported in WebKit (hence some of Kent's comments). As such we are suspending this work until that change has been made.
Comment 11 Stephen Chenney 2013-04-09 17:07:10 PDT
Marked LayoutTest bugs, bugs with Chromium IDs, and some others as WontFix. Test failure bugs still are trackable via TestExpectations or disabled unit tests.