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

Popover component overlay not fully visible in Customizer #43678

Open
JoryHogeveen opened this issue Aug 29, 2022 · 7 comments
Open

Popover component overlay not fully visible in Customizer #43678

JoryHogeveen opened this issue Aug 29, 2022 · 7 comments
Labels
[Feature] Widgets Customizer Ability to add and edit blocks in Customize → Widgets. [Type] Bug An existing feature does not function as intended

Comments

@JoryHogeveen
Copy link

JoryHogeveen commented Aug 29, 2022

Description

Related: #41739

The issue here is that in previous versions (current WP included version) the popover component was positioned fixed and with the latest Gutenberg updates it changes to absolute because the is_expanded class never gets added. I believe this might be the cause here. The popover to respect overflow and other containers to stay within their boundaries.

The issue started since this commit: 8b14921#diff-7895f8092f907d624abdbe647e2201f1cebe9198cd3fae6ba759b70a4c0bfef4

As you can see in /packages/components/src/popover/style.scss it removed the fixed position from the .components-popover element.
It adds this in the &.is-expanded version though this class never gets added unfortunately.

Step-by-step reproduction instructions

Create a popover color picker within the customizer. The color picker is partially hidden.

Screenshots, screen recording, code snippet

image

Environment info

  • WordPress 6.1 alpha (also with previous releases
  • Any browser
  • Gutenberg v13.x

The screenshot example is made with the GeneratePress theme but any theme which includes a popover color picker will do fine to reproduce.

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

@talldan talldan added [Type] Bug An existing feature does not function as intended [Feature] Widgets Customizer Ability to add and edit blocks in Customize → Widgets. labels Aug 30, 2022
@talldan
Copy link
Contributor

talldan commented Aug 30, 2022

This seems to be happening with some core blocks. A couple of examples:

  • The link control on a paragraph block:

Screen Shot 2022-08-30 at 2 35 12 pm

  • The color control on a group block (in the block settings):

Screen Shot 2022-08-30 at 2 36 16 pm

@ciampo
Copy link
Contributor

ciampo commented Sep 5, 2022

It looks like popovers are already intended to render in a special slot when they are in the customizer:

// We have to portal this to the parent of both the editor and the inspector,
// so that the popovers will appear above both of them.
const popover =
parentContainer &&
createPortal(
<div className="customize-widgets-popover" ref={ popoverRef }>
<Popover.Slot />
</div>,
parentContainer
);

When rendered in this ad-hoc wrapper, there are style overrides to enforce the fixed position:

.customize-control-sidebar_block_editor .block-editor-block-list__block-popover {
// FloatingUI library used in Popover component forces us to have an "absolute" inline style.
// We need to override this in the customizer.
position: fixed !important;
z-index: z-index(".customize-widgets__block-toolbar");
}
.customize-widgets-popover .components-popover {
// FloatingUI library used in Popover component forces us to have an "absolute" inline style.
// We need to override this in the customizer.
position: fixed !important;
}

So I guess that one way to fix this bug is to make sure that all popovers being currently affected by the issue reported above, get effectively rendered in the above slot correctly

@ciampo
Copy link
Contributor

ciampo commented Sep 21, 2022

Hey @talldan , would #44282 be fixing this issue too?

@talldan
Copy link
Contributor

talldan commented Sep 21, 2022

I'm not sure that PR is wide enough in scope to fix the bug for plugins or themes that use @wordpress/components in the customizer (which seems to be what's happening in the screenshot).

Those plugins/themes could implement similar fixes. I'm a bit short of ideas on how to fix it beyond that other than changing everything back to fixed positioning.

@brendanaw
Copy link

Hi guys I am using kadence theme and am experiencing the same issue. Is there a fix for this?

@mleathem
Copy link

mleathem commented Apr 18, 2023

Ping! Issue is open for 232 days and counting...

UPDATE: ... Issue now fixes for me! -
( You may want to review if this issue has generally been now fixed. )
I played around, and somewhere in updating plugins, and de-activating / activating themes, the issue was fixed.
NOTE: themes and core were already up-to-date


I'm just looking into this (same/similar ??) issue with our theme... so can't comment much - seems to be this issue (POPOVER is hidden under the right sidebar.
INFO: this bug happens when trying to set color (set in theme.json).

image
[ NOTE the horiz. scrollbar ]

Offending popover slot code is:
<div class="popover-slot"><div class="components-popover components-dropdown__content is-positioned" tabindex="-1" data-projection-id="56" style="position: absolute; top: 0px; left: 0px; ....

I can force the POPOVER into view by adding CSS position to `.popover-slot - but the left px value needed is never consistent (I assume its getting dynamically re-positioned every time the slot is rendered )
Note: once I force it in view the content of the POPOVER is as expected.

Aside: IMO, WordPress' biggest downside is suddenly discovering something is broken, and trying to track down the "when and why" of it... Sure I understand it happens, but core updates should never be breaking changes (unless absolutely unavoidably).

@ciampo
Copy link
Contributor

ciampo commented Apr 27, 2023

UPDATE: ... Issue now fixes for me! -

Hey @mleathem , glad to hear that issue got fixed on your end.

Ping! Issue is open for 232 days and counting...

There were already a few messages sharing advice on how to implement a fix if needed (see #43678 (comment) and #43678 (comment)).

While I understand that such a bug may be inconvenient, I would also remind you that this is an open-source project in which everyone does their best work while keeping the interest of the community in mind.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Widgets Customizer Ability to add and edit blocks in Customize → Widgets. [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

No branches or pull requests

5 participants