Make :enabled the complement of :disabled, fieldsets included

[jdalton]

Summary

:disabled walks up the tree looking for a disabled <fieldset>, the way the HTML spec asks it to, but :enabled only reads the element's own disabled property. An <input> inside a disabled fieldset therefore matches both pseudo-classes at once, which no browser does.

This moves the rule into one isDisabled() helper that both pseudo-classes ask, so they cannot disagree, and fixes two more cases the old walk got wrong along the way.

What the two pseudo-classes answer before and after, on one document

<input id=i1 disabled>
<input id=i2>
<fieldset id=fs disabled>
  <legend id=lg><input id=li1></legend>
  <input id=fi1>
  <fieldset id=fsin><input id=fi3></fieldset>
</fieldset>
<select><optgroup id=og disabled><option id=op1>a</option></optgroup></select>

Before this change, fi1, fsin and fi3 all match :enabled and :disabled together. After it, nothing matches both, and each element lands where Chromium puts it: li1 is enabled because it sits in the fieldset's first legend, fi1 and fi3 are disabled by the fieldset above them, and op1 is disabled by its optgroup.

Why the rule is shaped this way, and where browsers implement it

Three parts of the spec rule are easy to lose, and the previous code lost two of them.

A <legend> excuses only the fieldset it belongs to, so the walk has to carry on outward rather than stop at the first disabled fieldset it finds an excuse for. Blink keeps the legend ancestor it last saw and compares it against that fieldset's own first legend before continuing, in listed_element.cc#L702.

An <option> is disabled by the <optgroup> it is a child of, whose own disabled property reflects only that optgroup's attribute, so the option has to read its parent.

And the two pseudo-classes are one predicate seen from both sides. Blink's MatchesEnabledPseudoClass() is exactly !IsDisabledFormControl(), in html_form_control_element.cc#L337, where the disabled side is IsActuallyDisabled() — the element's own attribute or the ancestor state — in listed_element.cc#L738.

The spec text is enabling and disabling form controls.

The two read-* pseudo-classes were reading the same property

:read-only and :read-write also asked for the element's own disabled, so a control inside a disabled fieldset came out read-write. They ask the new helper now, which is why the diff touches them.

On the document above, Chromium answers fieldset :read-write with li1 and nothing else from inside the disabled fieldset. Before this change the engine also returned fi1 and fi3.

References: the spec, the browser source, and what each part was reasoned from

This patch applies to master on its own. The sixteen in this series were checked by cherry-picking them onto master one after another, in this order and in reverse, and all sixteen land without a conflict.

• Spec: enabling and disabling form controls the disabled attribute — the fieldset, legend and optgroup rules.
• Spec: enableddisabled — :enabled and :disabled as complements.
• Chromium: listed_element.cc#L702 — the ancestry walk, including why it continues past a legend.
• Chromium: listed_element.cc#L738 — IsActuallyDisabled(): the own attribute or the ancestor state.
• Chromium: html_form_control_element.cc#L337 — the two pseudo-classes as one predicate.
• MDN: :disabled.