EuiValidatableControl: useEffect for setCustomValidity causes race with native form validation

[ghudgins]

Warning: THIS WAS VIBE TROUBLESHOT BUT THE LLM SAYS IT IS, AND I QUOTE, "VERY CONFIDENT"
Context from Kibana issue....apologies to those not in Elastic for not being able to see this

EuiValidatableControl uses useEffect to call setCustomValidity('Invalid') on the underlying DOM element when isInvalid changes. Because useEffect runs after paint, there is a one-frame window where the DOM element's validity is stale relative to React state. If a form submit (via type="submit" button) fires during this window, the browser's native constraint validation sees the stale customValidity and shows a native "Invalid" tooltip—even though React has already cleared isInvalid.

Relevant code (validatable_control.js):

useEffect(function () {
  if (controlEl == null || typeof controlEl.setCustomValidity !== 'function') return;
  if (isInvalid) {
    controlEl.setCustomValidity('Invalid');
  } else {
    controlEl.setCustomValidity('');
  }
}, [isInvalid, controlEl]);

Suggested fix: Replace useEffect with useLayoutEffect, which runs synchronously before paint:

useLayoutEffect(function () {
  if (controlEl == null || typeof controlEl.setCustomValidity !== 'function') return;
  if (isInvalid) {
    controlEl.setCustomValidity('Invalid');
  } else {
    controlEl.setCustomValidity('');
  }
}, [isInvalid, controlEl]);

This closes the timing gap between React state and DOM validity state, preventing stale native validation tooltips.

Affects: Any EUI form control (EuiFieldText, EuiTextArea, etc.) inside a <form> without noValidate that toggles isInvalid during user interaction.

[acstll]

It seems to me like the controlEl.setCustomValidity('Invalid') call is a smell. The main purpose of the setCustomValidity API is to ultimately display a real custom message (not just "Invalid") in that native not-so-nicely-looking tooltip.

It might be being a bit misused in EUI in order to target elements only for styling of invalid states. Which in part is being handled inconsistently across control components e.g.

• field_text → :is(:invalid, [aria-invalid='true'])
• field_number → [aria-invalid='true']
• field_password, field_search, select, text_area → &:invalid only

I wonder if we could drop the setCustomValidity call completely, and unify invalid selectors (probably to match [aria-invalid='true']).

I'm going to have Claude open a draft PR so we can, first validate this assumption, and also throw it in Kibana to make sure we're not breaking anything.