Skip to content
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.

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

Fix vertical overflow when inserter is open in post and site editor #57127

Conversation

 colorful-tones
Copy link
Member

What?

Addresses #56811

This needs further cross browser testing, but addresses the initial issue in Chrome desktop.

How?

Adding a class to the InterfaceSkeleton component in the site editor and post editor: is-inserter-opened . Target the class with overflow: hidden .

Testing Instructions

  1. Open the site editor (not sure if it happens in the post editor)
  2. Open the inserter
  3. Start typing and verify there is no odd vertical scrolling for the entire canvas, including the main canvas

 @t-hamano
Copy link
Contributor

Perhaps the following CSS alone can solve the problem?

 . block-editor-inserter__main-area { overflow : hidden; }

Copy link
Contributor

 @andrewserong andrewserong left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more .

Thanks for looking into this @colorful-tones ! This is testing nicely for me so far 👍

Just checking, is it safe to set overflow: hidden on the interface-interface-skeleton__body ? From memory, hidden sets a formatting context that can interfere with position: sticky rules, so it's possible that this could adversely affect things within the editor canvas. In practice, from testing setting a Group block to Sticky in both an iframed and a non-iframe editor, this seems to be working well for me so far 🤔

A couple of other thoughts: do we know what's causing the overflow to be present? Is it possible to contain another area that's unintentionally causing the skeleton body to overflow rather than hiding it with the hidden rule, or alternately, would it be worth trying overflow: clip in case we want to avoid the formatting context?

One thing I've noticed is that it can sometimes be quite tricky to make changes to some of these parts of the editor canvas without unintentionally introducing side effects, so it could be good to get a couple more pairs of eyes on whichever approach we'd like to go with here, just in case 🙂

@@ -69,6 +69,12 @@ html.interface-interface-skeleton__html-container {
padding-bottom : $button-size-small + $border-width ;
}
}

// Prevent unneccessary infinite empty scrolling when empty block canvas
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more .

What's the infinite empty scrolling? In manual testing on trunk it looks like the editor is scrolling nearly a full height of the editor, rather than infinite. Apologies if I'm missing something here!

 @andrewserong
Copy link
Contributor

Perhaps the following CSS alone can solve the problem?

Apologies, I didn't see that comment before I submitted my review. That's sounding promising if we can limit the area where we're applying overflow: hidden 👍

 @t-hamano
Copy link
Contributor

t-hamano commented Dec 18, 2023

I looked into this issue a little more closely. The root cause may be that when you enter a search keyword, there is no element with overflow:hidden applied above the scroll element.

Default

 < div  class =" block-editor-inserter__menu " >  <!--   ← overflow:visible; -->
	 < div  class =" block-editor-inserter__main-area show-as-tabs " >
		 < div  class =" block-editor-inserter__search " > </ div >
		 < div  class =" block-editor-inserter__tabs " >  <!--   ← overflow:hidden; -->
			 < div  role =" tabpanel " >  <!--   ← overflow-y: auto; -->
				 <!--  Block List here... -->
			 </ div >
		 </ div >
	 </ div >
 </ div >

When entering a search keyword

 < div  class =" block-editor-inserter__menu " >  <!--   ← overflow:visible; -->
	 < div  class =" block-editor-inserter__main-area " >
		 < div  class =" block-editor-inserter__search " > </ div >
		 < div  class =" block-editor-inserter__no-tab-container " >  <!--   ← overflow-y: auto; -->
			 <!--  Block List here... -->
		 </ div >
	 </ div >
 </ div >

There may be several ways to solve this problem with CSS.

  1. Apply overflow:hidden; to elements with block-editor-inserter__menu class: Currently, overflow: hidden; is applied, but this style seems to have not changed for over 3 years . Changing this to hidden might have some issues.
  2. Apply overflow:hidden; to the element with .block-editor-inserter__main-are class : This is the approach I suggested in this comment .
  3. Wrapping the element with block-editor-inserter__no-tab-container class: In addition to adding overflow:hidden to the wrapped element, we may need to adjust some styles.

Personally, I think the second, simpler approach is better. However, a third approach that matches nested structures regardless of whether a search term is present or not seems good. In other words, there is an element with overflow:hidden applied in parallel to an element with the block-editor-inserter__search class, and a scroll element directly below it.

 @colorful-tones
Copy link
Member Author

Lots of great feedback. I plan on taking another pass at this today. Thanks!

 @colorful-tones
Copy link
Member Author

Perhaps the following CSS alone can solve the problem?

That certainly fixes the issue in Chrome. I have yet to do any cross-browser testing, but I certainly will before moving to finalizing any PRs.

  1. Wrapping the element with block-editor-inserter__no-tab-container class: In addition to adding overflow:hidden to the wrapped element, we may need to adjust some styles.

Personally, I think the second, simpler approach is better. However, a third approach that matches nested structures regardless of whether a search term is present or not seems good. In other words, there is an element with overflow:hidden applied in parallel to an element with the block-editor-inserter__search class, and a scroll element directly below it.

I am not clear on this last suggestion. 🤔

Thanks for the guidance @t-hamano

 @t-hamano
Copy link
Contributor

t-hamano commented Dec 19, 2023

I am not clear on this last suggestion. 🤔

Sorry for the insufficient explanation. I was wondering if it would be possible to change the hierarchy as shown below when the search text is entered.

From:

 < div  class =" block-editor-inserter__menu " >  <!--   ← overflow:visible; -->
	 < div  class =" block-editor-inserter__main-area " >
		 < div  class =" block-editor-inserter__search " > </ div >
		 < div  class =" block-editor-inserter__no-tab-container " >  <!--   ← overflow-y: auto; -->
			 <!--  Block List here... -->
		 </ div >
	 </ div >
 </ div >

To:

 < div  class =" block-editor-inserter__menu " >  <!--   ← overflow:visible; -->
	 < div  class =" block-editor-inserter__main-area " >
		 < div  class =" block-editor-inserter__search " > </ div >
		 < div  class =" block-editor-inserter__no-tab-container " >  <!--   ← overflow: hidden; -->
			 < div  class =" block-editor-inserter__search-results " >  <!--   ← overflow-y: auto; -->
				 <!--  Block List here... -->
			 </ div >
		 </ div >
	 </ div >
 </ div >

However, when I tried this locally, I was unable to resolve the overflow 😅 Therefore, if it can be solved in all browsers, the following approach may be better.

  1. Apply overflow:hidden; to the element with .block-editor-inserter__main-are class : This is the approach I suggested in this comment .

 @t-hamano t-hamano added [Type] Bug An existing feature does not function as intended [Feature] Inserter The main way to insert blocks using the + button in the editing interface labels Dec 19, 2023
 Co-authored-by: Aki Hamano <54422211+ t-hamano@users.noreply.github.com >
 @colorful-tones
Copy link
Member Author

I've used @t-hamano suggested fix and reverted my previous attempts. I also attempted to give co-authored attribution in commit. 🤞

I opted to only target overflow-y: hidden to only target what is needed and not target shorthand, which would influence x-axis as well.

I've tested the fix in both the site editor and the block editor for the following desktop browsers.

  • Chrome 120 site editor and block editor
  • Safari 17.2 site editor and block editor
  • MS Edge 120 site editor and block editor
  • Firefox 120 site editor and block editor

I'm attaching videos of all the results. So far it is working nicely. I plan on circling back to do some mobile and tablet testing in iOS simulator, but could use some help with any Android and any other browsers. Thanks!

Safari-desktop-17.2-site-editor.mp4
Safari-desktop-17.2-block-editor.mp4
MS-Edge-120-site-editor.mp4
MS-Edge-120-block-editor.mp4
firefox-120-site-editor.mp4
Firefox-120-block-editor.mp4
Chrome-120-site-editor.mp4
Chrome-120-block-editor.mp4

 @t-hamano t-hamano self-requested a review December 19, 2023 16:14
Copy link
Contributor

 @t-hamano t-hamano left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more .

LGTM ! Thank you for including me as a co-author 😊

I'm using Windows OS, but Chrome, Firefox, and Edge all seem to work fine. However, I would like to ask @andrewserong if this approach is correct 🙇

 @colorful-tones
Copy link
Member Author

colorful-tones commented Dec 19, 2023

Tested on iPhone 15 Pro Max (iOS 17.2) and there are no regressions and everything seems to operate smoothly in both the site editor and the block editor.

Before (Gutenberg 17.2.3) After (with patch applied)
https://github.com/WordPress/gutenberg/assets/405912/ad82f929-cebb-4464-8460-3dd8dc7f66af https://github.com/WordPress/gutenberg/assets/405912/bf93f951-d532-41f5-a219-670237c9f81b
https://github.com/WordPress/gutenberg/assets/405912/869aa68a-7223-4c56-a21f-1d64102bae15 https://github.com/WordPress/gutenberg/assets/405912/27b5e909-18e3-4e54-9db3-a3a60545b18b

Note: there are a few oddities on Gutenberg 17.2.3 which are featured in the block editor video above, but they're not related to the work for this fix and they're working fine in my branch. So, they've likely been addressed elsewhere. The most noticeable is when clicking 'Add New Post' and landing on the block editor it zooms way in and you just see a giant plus + icon.

Copy link
Contributor

 @andrewserong andrewserong left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more .

Nice work honing in on a safe fix @colorful-tones and @t-hamano ! Using .block-editor-inserter__main-area feels like a good way to keep the rule contained to me, and makes for a simple fix 👍

Tested in the post and site editors using Safari, Chrome, Edge, and Firefox on a Mac. In each case there were no additional scrollbars, and I found no regressions with any part of the inserter that I could test.

I think we've tested pretty thoroughly in different environments now, so this LGTM!

 @andrewserong andrewserong merged commit 6bbf33c into WordPress : trunk Dec 20, 2023
51 checks passed
 @github-actions github-actions bot added this to the Gutenberg 17.4 milestone Dec 20, 2023
artemiomorales pushed a commit that referenced this pull request Jan 4, 2024
 …57127 ) * Toggle classname for inserter * Adjust overflow when inserter is open * Revert "Toggle classname for inserter" This reverts commit 95f0a72 . * Revert "Adjust overflow when inserter is open" This reverts commit 40fba9e . * Fix vertical overflow for inserter main area Co-authored-by: Aki Hamano <54422211+ t-hamano@users.noreply.github.com > --------- Co-authored-by: Aki Hamano <54422211+ t-hamano@users.noreply.github.com >
 @jeryj
Copy link
Contributor

I'm not sure why, but this issue is caused by the downloadable block lists. Adding this fixes it and the overflow can be removed:

 .block-directory-downloadable-blocks-list { position: relative; }

I need overflow to be visible as part of fixing #60209 , so I'll probably be pinging y'all about this soon :)

Anyone have an idea of why that downloadble-blocks-list would be causing this, and why position relative would fix it?

 @t-hamano
Copy link
Contributor

I'm not sure why, but this issue is caused by the downloadable block lists. Adding this fixes it and the overflow can be removed:

I don't know why either, but certainly that style seems to solve the problem with overflow.

However, it seems that the problem is not resolved in all cases. For example, if you type "list" in the search box, the problem will be resolved, but if you type "a", the problem will occur.

 sidebar-overflow

After trying various things, it seems that applying position:relative to the element with the block-editor-inserter__no-tab-container class can solve the problem overall 🤔

 diff --git a/packages/block-editor/src/components/inserter/style.scss b/packages/block-editor/src/components/inserter/style.scss index ba1107054c..09c35f91c0 100644 --- a/packages/block-editor/src/components/inserter/style.scss
 +++ b/packages/block-editor/src/components/inserter/style.scss
 @@ -22,7 +22,6 @@ $block-inserter-tabs-height: 44px; flex-direction: column; height: 100%; gap: $grid-unit-20; - overflow-y: hidden; &.show-as-tabs { gap: 0; @@ -142,6 +141,7 @@ $block-inserter-tabs-height: 44px; .block-editor-inserter__no-tab-container { overflow-y: auto; flex-grow: 1; + position: relative; } .block-editor-inserter__panel-header {

Sign up for free to join this conversation on GitHub . Already have an account? Sign in to comment
Labels
[Feature] Inserter The main way to insert blocks using the + button in the editing interface [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Users can scroll off the bottom of the block editor into a forbidden void when searching in the inserter
4 participants