Components: Add allowForms prop to SandBox component by dhasilva · Pull Request #76471 · WordPress/gutenberg

dhasilva · 2026-03-12T22:49:38Z

What?

Why?

Currently there is no way to allow forms in the Sandbox component, so in cases where that is necessary, like submitting your date of birth to view age-restricted content, the submission is blocked.

How?

By adding an allowForms prop to the SandBox component that includes allow-forms to the iframe, making it possible to allow it selectively.

Testing Instructions

Storybook can be used for that.
1- Run storybook with npm run storybook:dev
2 - Go to Components > Utilities > SandBox > With Form
3 - Check that you can submit the form
4 - Disable allowForms and reload
5 - Check that you can't submit the form

Testing Instructions for Keyboard

Screenshots or screencast

Before	After

Use of AI Tools

Claude Code was used to generate tests.

github-actions · 2026-03-12T22:49:46Z

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

Required label: Any label starting with [Type].
Labels found: .

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

github-actions · 2026-03-12T22:49:47Z

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: dhasilva <thehenridev@git.wordpress.org>
Co-authored-by: jsnajdr <jsnajdr@git.wordpress.org>
Co-authored-by: aduth <aduth@git.wordpress.org>
Co-authored-by: CGastrell <cgastrell@git.wordpress.org>
Co-authored-by: simison <simison@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: talldan <talldanwp@git.wordpress.org>

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

aduth · 2026-03-13T12:37:58Z

I think I'd like to understand why the existing sandbox default values allow-scripts allow-same-origin allow-presentation were selected, and whether allow-forms is a reasonable inclusion in that default set aligned with the original implementation, rather than adding more options for individual sandbox properties. Arguably those (especially allow-scripts) are a lot more "risky" than allowing form submissions.

dhasilva · 2026-03-13T15:54:19Z

I think I'd like to understand why the existing sandbox default values allow-scripts allow-same-origin allow-presentation were selected, and whether allow-forms is a reasonable inclusion in that default set aligned with the original implementation, rather than adding more options for individual sandbox properties. Arguably those (especially allow-scripts) are a lot more "risky" than allowing form submissions.

That is a good point. The prop idea came from this comment in the issue, though reading it again I'm not sure if by "it" @talldan meant the "allow-forms" specifically, or all values.

CGastrell · 2026-03-23T15:20:22Z

Seems safe:

Opt-in only — allowForms defaults to false, so no existing behavior changes. All current consumers of SandBox are unaffected.
allow-forms is lower risk than what's already allowed — The sandbox already grants allow-scripts and allow-same-origin, which are significantly more powerful capabilities. allow-forms just lets form elements submit; it doesn't grant script execution or cross-origin access that isn't already present.
Tests are solid — Both the positive and negative cases are covered.

Issues / suggestions

Trailing space in sandbox attribute — When allowForms is false, the template literal produces a trailing space: allow-scripts allow-same-origin allow-presentation ${false ? 'allow-forms' : ''}
yields "allow-scripts allow-same-origin allow-presentation ". This is functionally harmless (browsers trim it), but it's a bit sloppy. The test uses expect.not.stringContaining('allow-forms') which passes despite the trailing space, so it works — but a .trim() or building an array and joining would be cleaner.
@aduth's raises a good point: given that allow-scripts and allow-same-origin are already in the default set (and are more dangerous), should allow-forms just be included by default rather than requiring a new prop? This would be simpler and avoid prop proliferation. The counter-argument is that the prop approach is more conservative and gives consumers explicit control. Both are reasonable, but this should be considered/addressed before merging.
Minor: The story form's action="#" will cause a navigation inside the iframe on submit, which is fine for demo purposes but could be confusing. A would make the demo cleaner.

The implementation seems correct and safe and tests well — it's a small, well-scoped, backwards-compatible addition. The main open question is what @aduth raised: prop vs. default. That's a project-level API design decision, not an actual issue. The trailing whitespace is a minor nit.

simison · 2026-07-28T13:39:15Z

Is this still needed/relevant?

We've recently added "allow popups" prop so there's pre-existing pattern.

aduth · 2026-07-28T14:04:20Z

Thanks for flagging @simison . It feels like there's parallel conversations happening between here and #69617, and that both pull requests are basically doing the same thing for different aspects of the sandbox.

I don't feel like it was ever really settled whether these make sense as defaults or if we should just open up the entire sandbox attribute, rather than do this piecemeal.

cc @Mamaduka @obenland @Imran92 @jsnajdr @mirka as having participated in that other pull request.

Mamaduka · 2026-07-29T08:10:47Z

Thanks for the ping. This would require rebasing after #69617.

Now it's worth deciding on the format we plan to support new allow-* tokens for the Sandbox component. Are we going with the current direction and require a new prop for each case, or allow consumers to pass tokens as needed, while retaining the required ones?

jsnajdr · 2026-07-29T11:48:10Z

Adding another allowForms prop looks fine to me. Simple and ergonomic.

Both allowForms and allowPopups are being added to fix the VideoPress block embed. Allow users to open links in a new tab, and submit an age-verification form.

That raises a question: should we enable these capabilities by default? The Sandbox component is used by the Cover and Embed blocks to display embed preview markup loaded from the generic /oembed/1.0/proxy endpoint. What if one of the registered embeds starts returning markup that is interactive enough to require these sandbox capabilities? Then we'll have to update the generic usages of Sandbox anyway.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

dhasilva · 2026-08-04T22:38:40Z

Rebased.

jsnajdr

Looks good. I pushed one more little commit that updates the Storybook component manifest.

* VideoPress: allow submitting the age gate birth date in the editor The editor renders the player inside Gutenberg's SandBox, and an iframe's sandbox flags are inherited by every nested browsing context — including the videopress.com player frame that hosts the age gate. Without `allow-forms` the birth date submission was blocked, so "Continue" did nothing. Opt into the `allowForms` prop added in WordPress/gutenberg#76471. It is not in the @wordpress/components version this package builds against yet, so the component is widened locally to accept it; versions without the prop ignore it and the age gate stays as blocked as it is today. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * VideoPress: refresh the player when a video's rating changes `rating` was synced to the VideoPress API on save but was missing from `invalidateEmbedResolutionFields`, so `getEmbedPreview` kept serving the cached HTML with the old age gate. The gate only disappeared once another attribute that is on that list changed, or the page was reloaded. The rating is not part of the embed URL either, so — unlike `loop`, `autoplay` and friends — it had no implicit cache miss to fall back on. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * VideoPress: add changelog entry Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

* VideoPress: allow submitting the age gate birth date in the editor The editor renders the player inside Gutenberg's SandBox, and an iframe's sandbox flags are inherited by every nested browsing context — including the videopress.com player frame that hosts the age gate. Without `allow-forms` the birth date submission was blocked, so "Continue" did nothing. Opt into the `allowForms` prop added in WordPress/gutenberg#76471. It is not in the @wordpress/components version this package builds against yet, so the component is widened locally to accept it; versions without the prop ignore it and the age gate stays as blocked as it is today. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * VideoPress: refresh the player when a video's rating changes `rating` was synced to the VideoPress API on save but was missing from `invalidateEmbedResolutionFields`, so `getEmbedPreview` kept serving the cached HTML with the old age gate. The gate only disappeared once another attribute that is on that list changed, or the page was reloaded. The rating is not part of the embed URL either, so — unlike `loop`, `autoplay` and friends — it had no implicit cache miss to fall back on. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * VideoPress: add changelog entry Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Committed via a GitHub action: https://github.com/Automattic/jetpack/actions/runs/31040061579 Upstream-Ref: Automattic/jetpack@7057a20

sirreal · 2026-08-12T07:04:17Z

Recategorizing this as type: enhancement.

* add allowForms prop to SandBox component * add allowForm to storybook * Add tests for SandBox allowForms prop Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * add changelog entry * Update Storybook manifest --------- Co-authored-by: dhasilva <thehenridev@git.wordpress.org> Co-authored-by: jsnajdr <jsnajdr@git.wordpress.org> Co-authored-by: aduth <aduth@git.wordpress.org> Co-authored-by: CGastrell <cgastrell@git.wordpress.org> Co-authored-by: simison <simison@git.wordpress.org> Co-authored-by: Mamaduka <mamaduka@git.wordpress.org> Co-authored-by: talldan <talldanwp@git.wordpress.org>

dhasilva requested review from a team and ajitbohra as code owners March 12, 2026 22:49

github-actions Bot added the [Package] Components /packages/components label Mar 12, 2026

simison requested review from ciampo and mirka March 13, 2026 06:21

CGastrell added the [Type] Task Issues or PRs that have been broken down into an individual action to take label Mar 23, 2026

github-actions Bot mentioned this pull request Mar 26, 2026

Add GitHub Action to detect overlapping PRs #76820

Open

dhasilva and others added 4 commits August 4, 2026 18:33

add allowForms prop to SandBox component

cf9da28

add allowForm to storybook

0aa2986

Add tests for SandBox allowForms prop

17e64bf

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

add changelog entry

aaac604

dhasilva force-pushed the fix/components-sandbox-allow-forms branch from 9a1899a to aaac604 Compare August 4, 2026 21:41

Update Storybook manifest

cbbfb7c

jsnajdr approved these changes Aug 5, 2026

View reviewed changes

jsnajdr enabled auto-merge (squash) August 5, 2026 08:56

jsnajdr merged commit 11bae0c into WordPress:trunk Aug 5, 2026
60 checks passed

github-actions Bot added this to the Gutenberg 23.8 milestone Aug 5, 2026

dhasilva mentioned this pull request Aug 5, 2026

VideoPress: fix the age gate in the block editor Automattic/jetpack#51069

Merged

dhasilva deleted the fix/components-sandbox-allow-forms branch August 5, 2026 16:20

dhasilva mentioned this pull request Aug 5, 2026

VideoPress: remove the SandBoxWithForms type cast once @wordpress/components ships allowForms Automattic/jetpack#51072

Open

sirreal added [Type] Enhancement A suggestion for improvement. and removed [Type] Task Issues or PRs that have been broken down into an individual action to take labels Aug 12, 2026

Navigation Menu

Uh oh!

Components: Add allowForms prop to SandBox component - #76471

Components: Add allowForms prop to SandBox component#76471
jsnajdr merged 5 commits into
WordPress:trunkfrom
dhasilva:fix/components-sandbox-allow-forms

dhasilva commented Mar 12, 2026

Uh oh!

github-actions Bot commented Mar 12, 2026

Uh oh!

github-actions Bot commented Mar 12, 2026 •

edited

Loading

Uh oh!

aduth commented Mar 13, 2026

Uh oh!

dhasilva commented Mar 13, 2026

Uh oh!

CGastrell commented Mar 23, 2026

Uh oh!

simison commented Jul 28, 2026

Uh oh!

aduth commented Jul 28, 2026

Uh oh!

Mamaduka commented Jul 29, 2026

Uh oh!

jsnajdr commented Jul 29, 2026

Uh oh!

dhasilva commented Aug 4, 2026

Uh oh!

jsnajdr left a comment

Uh oh!

Uh oh!

sirreal commented Aug 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

Uh oh!

Conversation

dhasilva commented Mar 12, 2026

What?

Why?

How?

Testing Instructions

Testing Instructions for Keyboard

Screenshots or screencast

Use of AI Tools

Uh oh!

github-actions Bot commented Mar 12, 2026

Uh oh!

github-actions Bot commented Mar 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

aduth commented Mar 13, 2026

Uh oh!

dhasilva commented Mar 13, 2026

Uh oh!

CGastrell commented Mar 23, 2026

Uh oh!

simison commented Jul 28, 2026

Uh oh!

aduth commented Jul 28, 2026

Uh oh!

Mamaduka commented Jul 29, 2026

Uh oh!

jsnajdr commented Jul 29, 2026

Uh oh!

dhasilva commented Aug 4, 2026

Uh oh!

jsnajdr left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

sirreal commented Aug 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

github-actions Bot commented Mar 12, 2026 •

edited

Loading