Bug 156558 – :in-range & :out-of-range CSS pseudo-classes shouldn't match inputs without range limitations

• Status: RESOLVED
• Resolution: FIXED
• Component: CSS

[Chris Rebert]

Created attachment 276361 [details]
Testcase demonstrating the bug

Steps to reproduce the problem:
1. Open the attached testcase in WebKit Nightly on OS X or in iOS 9.3 Safari.
2. Observe the background-colors and borders of the <input>s

What is the expected behavior?
The inputs should have neither a red border nor a red background-color,
because they don't have range limitations ( https://html.spec.whatwg.org/multipage/forms.html#have-range-limitations ),
because they have neither `min` nor `max` attributes
and the HTML spec doesn't define a default minimum or maximum for any of these input types.
Therefore, these inputs should fail the 2nd of the 3 conditions required to match :in-range or :out-of-range .

Per https://html.spec.whatwg.org/multipage/scripting.html#selector-in-range
> The :in-range pseudo-class must match all elements that are [...], have range limitations, and [...]

What went wrong?
The inputs have red borders and/or red backgrounds, indicating that they matched the :in-range or :out-of-range pseudo-classes despite not having range limitations.

[Chris Rebert]

Created attachment 276362 [details]
Screenshot of testcase on iOS

[Benjamin Poulain]

Created attachment 281406 [details]
Patch

[Benjamin Poulain]

Created attachment 281423 [details]
Patch

[Simon Fraser (smfr)]

Comment on attachment 281423 [details]
Patch

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

> Source/WebCore/html/InputType.cpp:343
> +        return false;

Shouldn't this return true? If the input has no range limitations, aren't you aways in-range?

> Source/WebCore/html/NumberInputType.cpp:170
> +        const AtomicString& minAttribute = element.fastGetAttribute(minAttr);
> +        Decimal minimumFromAttribute = parseToNumberOrNaN(minAttribute);
> +        if (minimumFromAttribute.isFinite()) {
> +            hasRangeLimitations = true;
> +            minimum = minimumFromAttribute;
> +        }

I think this could go into a separate function or lambda and be shared.

> Source/WebCore/html/StepRange.h:74
> +    StepRange(const Decimal& stepBase, bool hasRangeLimitations, const Decimal& minimum, const Decimal& maximum, const Decimal& step, const StepDescription&);

Please make an enum for hasRangeLimitations. The call sites are unreadable with this change.

[Benjamin Poulain]

(In reply to comment #4)
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=281423&action=review
> 
> > Source/WebCore/html/InputType.cpp:343
> > +        return false;
> 
> Shouldn't this return true? If the input has no range limitations, aren't
> you aways in-range?

The way the spec defines it, you are only in range if there is a valid range to begin with.
In this case, since you have no range or and invalid range, you are not in-range.

[Benjamin Poulain]

Created attachment 281480 [details]
Patch for landing

[WebKit Commit Bot]

Comment on attachment 281480 [details]
Patch for landing

Clearing flags on attachment: 281480

Committed r202143: <http://trac.webkit.org/changeset/202143>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Chris Rebert]

Wonderful! I look forward to the next Tech Preview release so that I can update http://caniuse.com/#feat=css-in-out-of-range to reflect this fix.

[Benjamin Poulain]

(In reply to comment #9)
> Wonderful! I look forward to the next Tech Preview release so that I can
> update http://caniuse.com/#feat=css-in-out-of-range to reflect this fix.

Your bug report was really high quality. Thanks a lot for taking the time to write a test case and highlight the relevant spec.