Open philnick206 opened 3 months ago
📌 REPRODUCTION RESULTS
📌 FINDINGS/SCREENSHOTS/VIDEO
📌 ACTIONS
High
to Low
Core Fix Needed
tag.@jartes I'm actually concerned that this issue has expanded beyond the Cover
block.
I have a user here who is experiencing the same issue: 8627130-zd-a8c
But when I tried to remove it from the Cover
block, that still wasn't enough - I had to completely remove it from the Header
and all nested elements in order to get it to work, I've provided screenshots below:
I'm sure it's related to the issue that you mentioned, but something seems to have changed and it's happening in more conditions now.
Support References
This comment is automatically generated. Please do not edit it.
Just wanted to update that @mxhassani was able to find a CSS
solution (at least for the Assembler
theme):
header.wp-block-template-part .wp-block-cover {
overflow: visible;
z-index: 99999;
}
Just wanted to update that @mxhassani was able to find a
CSS
solution (at least for theAssembler
theme):header.wp-block-template-part .wp-block-cover { overflow: visible; z-index: 99999; }
That workaround worked great for 8600675-zd-a8c
Thanks for sharing!
Hmmm, looks to be caused by the overflow rules on the cover block:
But those same rules are required for sticky positioning. 🤔 cc @andrewserong in case there's extra context here.
But those same rules are required for sticky positioning. 🤔 cc @andrewserong in case there's extra context here.
I think they might have been added originally to handle border radius (so that the background is properly clipped to the radius of the border). The switch to clip
instead of hidden
was added for support for sticky positioning. The rule has been there for a long time now, so I'm not sure what a decent fix could be, unless there's a way for the rule to apply in more of a conditional way, only when it's needed, somehow? The hard thing there would be for us to know if border radius is being applied, given that could be set globally.
Unfortunately the main thing that comes to mind is that the Cover block isn't an ideal block to use for anything that would involve popovers (considering its issues with overflow here). Is there a reason why folks are using Cover blocks for their headers instead of a Group block? I.e. if it's about background images, the Group block now has pretty comprehensive background image support. If it's about being able to add an overlay color, though, then perhaps it highlights that it'd be good for Group blocks to be able to support overlays, I wonder?
This might be a duplicate or likeness of this issue: https://github.com/Automattic/wp-calypso/issues/75439
This might be a duplicate or likeness of this issue: #75439
I just checked this one, and it seems there's another issue here related to overflow
in the cover block. So the original solution doesn't fix the submenus. It needs some more investigation to check the implications of removing the overflow
and possible workarounds.
Quick summary
Navigation blocks that are placed inside a Cover block and use submenus will have the submenus overlapped/hidden by subsequent blocks on the page.
Steps to reproduce
What you expected to happen
The Navigation submenus should always be visible on desktop screens
What actually happened
The Navigation submenus are hidden on desktop (ok on mobile in my testing)
Impact
Most (> 50%)
Available workarounds?
No but the platform is still usable
If the above answer is "Yes...", outline the workaround.
No response
Platform (Simple and/or Atomic)
No response
Logs or notes
Reported in 8600675-zd-a8c