8000 Unwanted scrollbars in Experimental Form block inspector dropdown · Issue #70306 · WordPress/gutenberg · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Unwanted scrollbars in Experimental Form block inspector dropdown #70306

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
4 of 6 tasks
himanshupathak95 opened this issue Jun 4, 2025 · 6 comments
Open
4 of 6 tasks

Unwanted scrollbars in Experimental Form block inspector dropdown #70306

himanshupathak95 opened this issue Jun 4, 2025 · 6 comments
Labels
[Feature] Block Variations Block variations, including introducing new variations and variations as a feature [Type] Bug An existing feature does not function as intended

Comments

@himanshupathak95
Copy link
Contributor
himanshupathak95 commented Jun 4, 2025 •
edited
Loading

Description

Discovered while working on #70249 and testing #70253

When opening the dropdown menu in the inspector controls of the Experimental Form block, both horizontal and vertical scrollbars appear unexpectedly. The scrollbars disappear when the dropdown is closed. This issue doesn't occur in other similar blocks like the Experimental Form Input block.

Expected behavior

The dropdown should:

  • Automatically adjust its width to fit content without horizontal scrolling
  • Only show vertical scroll when content exceeds viewport height
  • Maintain consistent styling with other block dropdowns

Current behavior

  • Horizontal scrollbar appears due to content overflow
  • Vertical scrollbar appears even when the content fits the viewport
  • The layout appears cramped with long text elements

Points of discussion -

  1. Shorten the variation text in variations.js
diff --git a/packages/block-library/src/form/variations.js b/packages/block-library/src/form/variations.js
index 5eab3e247f..149ea50763 100644
--- a/packages/block-library/src/form/variations.js
+++ b/packages/block-library/src/form/variations.js
@@ -61,7 +61,7 @@ const variations = [
 	},
 	{
 		name: 'wp-privacy-form',
-		title: __( 'Experimental Privacy Request Form' ),
+		title: __( 'Experimental Privacy Request' ),
 		keywords: [ 'GDPR' ],
 		description: __( 'A form to request data exports and/or deletion.' ),
 		attributes: {

Since it is a form block and the dropdown title, dropdown item description, and other contextual elements already support the 'form' keyword, this redundancy can be removed for better UX.

After investigating, I found that this was added in #44214 and modified in #51912 (just casing modifications)

  1. Remove the white-space: nowrap constraint and increase the min-width (if necessary)

The issue stems from the white-space: nowrap CSS rule introduced in the menu-item style.css file, which was added in #25218. This prevents text wrapping and causes horizontal overflow when menu items have long text. However, this would require a significant amount of testing.

gutenberg/packages/components/src/menu-item/style.scss

Lines 67 to 75 in a5e3592

.components-menu-item__item {
// Provide a minimum width for text items in menus.
white-space: nowrap;
min-width: 160px;
margin-right: auto;
display: inline-flex;
align-items: center;
}

  1. Adjust dropdown placement

Changing the dropdown placement in the DropdownMenu component:

gutenberg/packages/block-editor/src/components/block-variation-transforms/index.js

Lines 77 to 87 in a5e3592

<DropdownMenu
className={ className }
label={ __( 'Transform to variation' ) }
text={ __( 'Transform to variation' ) }
popoverProps={ {
position: 'bottom center',
className: `${ className }__popover`,
} }
icon={ chevronDown }
toggleProps={ { iconPosition: 'right' } }
>

I did not notice any significant difference when trying out various placement options, but I would like to mention this for completeness.

Note: The position prop in popoverProps is deprecated and should be replaced with the placement prop according to #44401, but this can be taken up in a different issue.

Step-by-step reproduction instructions

  1. Enable the experimental form and form input blocks from the Gutenberg plugin > Experiments
  2. Add an Experimental Form block to a new post
  3. Open the block inspector controls in the sidebar
  4. Click the dropdown under Experimental Comment form
  5. Observe unwanted horizontal and vertical scrollbars

Screenshots, screen recording, code snippet

Screen.Recording.2025-06-03.at.15.51.49.mov

Environment info

  • WordPress: Latest Trunk
  • PHP: 8.2.28
  • Browser: Chrome 137.0.0.0
  • OS: macOS
  • Theme: Twenty Twenty-Five 1.2

Please confirm that you have searched existing issues in the repo.

  • Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

  • Yes

Please confirm which theme type you used for testing.

  • Block
  • Classic
  • Hybrid (e.g. classic with theme.json)
  • Not sure
@himanshupathak95 himanshupathak95 added the [Type] Bug An existing feature does not function as intended label Jun 4, 2025
@himanshupathak95
Copy link
Contributor Author

I think the simplest fix would be the first point of discussion, but I would like this to be properly discussed before proceeding with a fix.

@SainathPoojary
Copy link
Contributor

I tested the first fix using the “Shorten the variation text in dropdown” approach, and it works well for this block. I’m okay with this patch as a solution for now. Additionally, I feel there should be a more general fix ideally one that handles longer strings by setting a maximum length, truncating excess text, and displaying the full content via a tooltip.

@t-hamano t-hamano added the [Feature] Block Variations Block variations, including introducing new variations and variations as a feature label Jun 4, 2025
@t-hamano
Copy link
Contributor
t-hamano commented Jun 4, 2025

Shorten the variation text in dropdown

Let's avoid this approach. It might solve the problem in the English locale, but not necessarily in other locales. We should always keep in mind that text length varies from locale to locale.

Additionally, this problem may occur in other blocks with long variation names.

Personally, I feel it's more natural to position the popover on the right:

Image

@himanshupathak95
Copy link
Contributor Author

Personally, I feel it's more natural to position the popover on the right:

@t-hamano I tried all the possible props for the position and placement props, and the only ones that do not cause the overflow are the ones that pop out on the left.

Could you please specify which placement prop worked for you?

@t-hamano
Copy link
Contributor
t-hamano commented Jun 6, 2025

Could you please specify which placement prop worked for you?

I used placement: 'bottom center'. However, because the dropdown itself has padding applied, the actual toggle button and the popover are visually misaligned. This will need to be adjusted.

Image

@carlomanf
Copy link

It would be better to delete this dropdown altogether, see #62904 for the reasons:

The experimental form suite still has a way to go before being viable for such a purpose. Most notably, the ability to transform between form variations via the inspector is of questionable value. If a user is customising their comment form, they would just be confused to see an option to transform it to a privacy request form. The embed block does not let you transform between variations, so why should the form block let you?

Similarly, being able to change the submissions method is likely to cause too much confusion and unintended destruction. It does not make any sense that a user should be able to submit their comment form or especially their login form by GET method. The form variations should be "siloed" such that once a variation is selected, the technical specifications are locked in and the form can only be used for the originally selected purpose.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
[Feature] Block Variations Block variations, including introducing new variations and variations as a feature [Type] Bug An existing feature does not function as intended
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@carlomanf @SainathPoojary @t-hamano @himanshupathak95
0