Bug 156530 - :in-range & :out-of-range CSS pseudo-classes shouldn't match disabled or readonly inputs
Summary: :in-range & :out-of-range CSS pseudo-classes shouldn't match disabled or read...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: WebKit Nightly Build
Hardware: All All
: P2 Normal
Assignee: Benjamin Poulain
URL: http://w3c-test.org/html/semantics/se...
Keywords: HasReduction, InRadar, W3CTest
Depends on:
Blocks:
 
Reported: 2016-04-12 20:07 PDT by Chris Rebert
Modified: 2016-06-16 22:19 PDT (History)
5 users (show)

See Also:


Attachments
Testcase demonstrating the bug (598 bytes, text/html)
2016-04-12 20:07 PDT, Chris Rebert
no flags Details
Patch (77.43 KB, patch)
2016-06-16 20:44 PDT, Benjamin Poulain
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Rebert 2016-04-12 20:07:54 PDT
Created attachment 276300 [details]
Testcase demonstrating the bug

Steps to reproduce the problem:
1. Open the attached testcase webpage in WebKit Nightly.
2. Observe the colors of the outlines of the <input>s.

What is the expected behavior?
The outlines should be green, indicating that the disabled or readonly <input type=number>s did not match the :in-range or :out-of-range CSS pseudo-classes.

What went wrong?
The outlines are orange and red, indicating that the disabled or readonly <input type=number>s matched the :in-range or :out-of-range CSS pseudo-classes.

----

Based on my reading of the HTML spec, :in-range and :out-of-range should never apply to disabled or readonly <input>s.

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

Per https://html.spec.whatwg.org/multipage/forms.html#candidate-for-constraint-validation
> A submittable element is a **candidate for constraint validation** except when a condition has **barred the element from constraint validation**.

Per https://html.spec.whatwg.org/multipage/forms.html#the-readonly-attribute:barred-from-constraint-validation
> If the **readonly** attribute is specified on an input element, the element is **barred from constraint validation**.

Per https://html.spec.whatwg.org/multipage/forms.html#enabling-and-disabling-form-controls:-the-disabled-attribute:barred-from-constraint-validation
> If an element is **disabled**, it is **barred from constraint validation**.

Thus, disabled and readonly <input>s are barred from constraint validation, meaning they are not candidates for constraint validation, thus causing them to be disqualified by the 1st of the 3 conditions which are required for an element to match :in-range or :out-of-range.
Comment 1 Radar WebKit Bug Importer 2016-04-12 23:04:51 PDT
<rdar://problem/25698037>
Comment 2 Chris Rebert 2016-04-19 22:38:45 PDT
Now fixed in Chrome: https://codereview.chromium.org/1890633002
Comment 3 Benjamin Poulain 2016-06-16 20:44:23 PDT
Created attachment 281527 [details]
Patch
Comment 4 Simon Fraser (smfr) 2016-06-16 20:56:19 PDT
Comment on attachment 281527 [details]
Patch

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

> Source/WebCore/html/BaseDateAndTimeInputType.cpp:98
> +    element().setNeedsStyleRecalc();

Is this necessary if the element has no renderer?

> Source/WebCore/html/NumberInputType.cpp:305
> +        renderer->setNeedsLayoutAndPrefWidthsRecalc();

Is this necessary in addition to the setNeedsStyleRecalc? Why are both required?
Comment 5 Benjamin Poulain 2016-06-16 21:01:53 PDT
(In reply to comment #4)
> Comment on attachment 281527 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=281527&action=review
> 
> > Source/WebCore/html/BaseDateAndTimeInputType.cpp:98
> > +    element().setNeedsStyleRecalc();
> 
> Is this necessary if the element has no renderer?

Definitely!
Style is independent from the render tree. You can handle on an offscreen subtree.

> > Source/WebCore/html/NumberInputType.cpp:305
> > +        renderer->setNeedsLayoutAndPrefWidthsRecalc();
> 
> Is this necessary in addition to the setNeedsStyleRecalc? Why are both
> required?

Yes.

The style recalc does not have to force a relayout. Here you also need the layout for properties independent from the style.
Comment 6 WebKit Commit Bot 2016-06-16 22:19:31 PDT
Comment on attachment 281527 [details]
Patch

Clearing flags on attachment: 281527

Committed r202159: <http://trac.webkit.org/changeset/202159>
Comment 7 WebKit Commit Bot 2016-06-16 22:19:35 PDT
All reviewed patches have been landed.  Closing bug.