Validated form controls: Suppress native popover by mirka · Pull Request #73471 · WordPress/gutenberg

mirka · 2025-11-20T20:51:18Z

What?

Closes #73015

Try suppressing the native error popover that appears when a form is validated, while keeping the focus behavior as is.

Why?

The popover can obscure our custom error messages, and are redundant.

How?

preventDefault() on invalid events on the validity target, and then add back the focus logic.

The concern here is whether we're overlooking any other "default behavior" that would be bad to prevent.

One that I noticed so far is, at least in VoiceOver on Chrome and Safari, hitting the submit button on an invalid form plays a special sound effect in addition to announcing the first error again. This behavior is lost by doing preventDefault(). We can mimic the announcement programmatically, but not the sound effect.

Testing Instructions

Try the Validated Form Control stories in the three major browsers.

Screenshots or screencast

Before

CleanShot.2025-11-21.at.05-26-35.mp4

After

CleanShot.2025-11-21.at.05-25-55.mp4

mirka · 2025-11-20T20:55:36Z

+		// Radio inputs need special handling because all radio inputs with the
+		// same `name` will be marked as invalid.
+		const radioSibilings =


One of the topics discussed in the original issue was whether this would be "worth the extra trouble".

So far, from the set of use cases that we currently have, radio inputs were the only thing that needed special handling like this. There may be more, and I have some qualms about the screen reader behavior, but perhaps not too bad to count as hard blockers.

I'm having a hard time understanding what happens if we just... didn't have this code for radio inputs.

My bad. Here's what happens when you click the submit button on an untouched radio group. The "Before" version has the radio handling in this hook commented out.

Before After

I expanded on the code comment a bit (793ace0). Ideally we have a unit test, but unfortunately this is not accurately testable in jsdom.

Gotcha 👍

Thinking out loud a bit: Rather than dealing with getValidityTarget as assuming there's some "one element" to be validated (which your comment seems to suggest is not actually the case), could we bind to the wrapper and watch for the event in capture phase?

Something like...

wrapperRef.current?.addEventListener( 'invalid', suppressNativePopover, true );

Or maybe it should be getValidityTargets, which is usually an array of one, but could be multiple?

Definitely not a blocker.

At the moment I'm not considering supporting multiple validity targets for a control, because there's only one slot to show an error message.

But listening to all invalid events within a control wrapper might work… 🤔 That might be preferable if we encounter additional cases that need a similar workaround.

github-actions · 2025-11-20T20:57:15Z

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: mirka <0mirka00@git.wordpress.org>
Co-authored-by: aduth <aduth@git.wordpress.org>
Co-authored-by: jasmussen <joen@git.wordpress.org>
Co-authored-by: juanfra <juanfra@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

mirka · 2025-11-20T20:57:48Z

Not sure if we'll merge, but I'll open this up to feedback.

jasmussen · 2025-11-21T07:55:21Z

At a very high level glance at just the before and after, purely conceptually the path forward is clear: it should be one or the other, not both.

mirka · 2025-12-08T21:05:13Z

I think we're all aligned that suppressing the native popovers is better for general UX. Since this is trivial to revert if it causes complications down the line, I would be comfortable trying it out to see how it goes.

I've rebased this with the latest validation logic, so the PR is ready for review (with the assumption that it will actually be merged) 🙂

aduth · 2025-12-08T21:47:05Z

+			);
+
+			expect(
+				screen.getByRole( 'textbox', { name: /^Text1/ } )


Nit: Should we expect that the name would be exactly Text1 ?

Suggested change

screen.getByRole( 'textbox', { name: /^Text1/ } )

screen.getByRole( 'textbox', { name: 'Text1' } )

This is just side-stepping the detail that the required prop adds a (Required) suffix to the labels. Kind of wanted to exclude that detail from these tests.

aduth · 2025-12-09T15:49:51Z

+			if ( ! target.form ) {
+				target.focus();
+				return;
+			}
+
+			const firstErrorInForm = Array.from( target.form.elements ).find(
+				( el ) => ! ( el as ValidityTarget ).validity.valid
+			);
+
+			if ( firstErrorInForm === target ) {
+				target.focus();
+			}


Could we use :invalid query selector to simplify this?

Suggested change

if ( ! target.form ) {

target.focus();

return;

}

const firstErrorInForm = Array.from( target.form.elements ).find(

( el ) => ! ( el as ValidityTarget ).validity.valid

);

if ( firstErrorInForm === target ) {

target.focus();

}

if ( ! target.form || target.form.querySelector( ':invalid' ) === target ) {

target.focus();

}

Ugh, this is a great idea I didn't think of, but unfortunately this querySelector( ':invalid' ) seems to trigger a recursive validation check in jsdom and makes every test hang 😭 I reshuffled the original code to make it a bit simpler though (41d019f).

aduth · 2025-12-09T15:51:02Z

+		// Radio inputs need special handling because all radio inputs with the
+		// same `name` will be marked as invalid.
+		const radioSibilings =


I'm having a hard time understanding what happens if we just... didn't have this code for radio inputs.

# Conflicts: # packages/components/CHANGELOG.md

aduth · 2025-12-10T19:21:03Z

+		// Radio inputs need special handling because all radio inputs with the
+		// same `name` will be marked as invalid.
+		const radioSibilings =


Gotcha 👍

Thinking out loud a bit: Rather than dealing with getValidityTarget as assuming there's some "one element" to be validated (which your comment seems to suggest is not actually the case), could we bind to the wrapper and watch for the event in capture phase?

Something like...

wrapperRef.current?.addEventListener( 'invalid', suppressNativePopover, true );

Or maybe it should be getValidityTargets, which is usually an array of one, but could be multiple?

Definitely not a blocker.

joedolson · 2026-03-19T15:51:03Z

I'm trying to assess this as I review accessibility related changes in 7.0, but I'm not sure where I can test this within core. Can you point me to some examples of inputs in core using this validation? I'm aware of the stories, but I want to be testing this in a use case.

mirka · 2026-03-19T17:47:49Z

@joedolson Thanks for looking at this. I believe the only use case in 7.0 is the LinkControl when you try to submit an invalid URL:

CleanShot.2026-03-20.at.02-45-04.mp4

joedolson · 2026-03-19T18:01:30Z

And it seems like there was no validation on that in 6.9, so it's actually a completely new addition, from the user perspective. Checking on it!

joedolson · 2026-03-19T18:05:34Z

No problems with suppressing the native error, but there is an issue with the error message - it's not explicitly connected to the input field; I'm going to open a new issue.

mirka self-assigned this Nov 20, 2025

mirka added [Type] Enhancement A suggestion for improvement. [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Package] Components /packages/components labels Nov 20, 2025

mirka commented Nov 20, 2025

View reviewed changes

mirka marked this pull request as ready for review November 20, 2025 20:57

mirka requested a review from ajitbohra as a code owner November 20, 2025 20:57

mirka requested review from a team November 20, 2025 20:58

mirka added 2 commits December 9, 2025 05:11

Validated form controls: Suppress native popover

fb82b7f

Add tests and story

4e9608c

mirka force-pushed the validation-suppress-popover branch from 115df92 to 4e9608c Compare December 8, 2025 20:46

Add changelog

51f6e8f

This was referenced Dec 8, 2025

Validated form controls: Add more validation examples #73488

Closed

Validated form controls: Add stories for validation in popovers #71282

Merged

aduth reviewed Dec 9, 2025

View reviewed changes

mirka added 4 commits December 10, 2025 21:13

Merge branch 'trunk' into validation-suppress-popover

00cbc8c

# Conflicts: # packages/components/CHANGELOG.md

Fix misspelling in function name

297b474

Add better explanation for radio handling

793ace0

Simplify first error finding

41d019f

mirka requested a review from aduth December 10, 2025 14:55

mirka mentioned this pull request Dec 10, 2025

Add URL validation in LinkControl using ValidatedInputControl #73486

Merged

aduth approved these changes Dec 10, 2025

View reviewed changes

mirka merged commit 0c606a3 into trunk Dec 11, 2025
46 of 47 checks passed

mirka deleted the validation-suppress-popover branch December 11, 2025 13:56

github-actions Bot added this to the Gutenberg 22.4 milestone Dec 11, 2025

	screen.getByRole( 'textbox', { name: /^Text1/ } )
	screen.getByRole( 'textbox', { name: 'Text1' } )

Conversation

mirka commented Nov 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What?

Why?

How?

Testing Instructions

Screenshots or screencast

Before

After

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Nov 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mirka commented Nov 20, 2025

Uh oh!

jasmussen commented Nov 21, 2025

Uh oh!

mirka commented Dec 8, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

joedolson commented Mar 19, 2026

Uh oh!

mirka commented Mar 19, 2026

Uh oh!

joedolson commented Mar 19, 2026

Uh oh!

joedolson commented Mar 19, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

mirka commented Nov 20, 2025 •

edited

Loading

github-actions Bot commented Nov 20, 2025 •

edited

Loading