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.
<rdar://problem/25698037>
Now fixed in Chrome: https://codereview.chromium.org/1890633002
Created attachment 281527 [details] Patch
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?
(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 on attachment 281527 [details] Patch Clearing flags on attachment: 281527 Committed r202159: <http://trac.webkit.org/changeset/202159>
All reviewed patches have been landed. Closing bug.