[Bug]: CSS container queries break Popover positioning

[bmv437]

Browser

Chrome

Package version

latest from live

React version

v18.3.1

Description

When a Popover component is rendered as a descendant of an element that uses CSS container queries with the container-type property set to size or inline-size, the position of the popover is no longer correct.

Here's a video of the behavior I'm seeing:

Screen.Recording.2025-03-18.at.11.40.40.AM.mov

I've included a reproduction as well.

Source code

No response

Reproduction

https://codesandbox.io/p/sandbox/container-broken-popover-nl3prj

Code of Conduct

• I agree to follow this project's Code of Conduct
• I checked the current issues for duplicate problems

[bmv437]

When searching around the internals, I did find this reference to the containerType computed property for the isContainingBlock check:

components/src/internal/utils/dom.ts

Lines 8 to 16 in 7ff86dc

	export function isContainingBlock(element: HTMLElement): boolean {
	const computedStyle = getComputedStyle(element);
	return (
	(!!computedStyle.transform && computedStyle.transform !== 'none') ||
	(!!computedStyle.perspective && computedStyle.perspective !== 'none') ||
	(!!computedStyle.containerType && computedStyle.containerType !== 'normal') ||
	computedStyle.contain?.split(' ').some(s => ['layout', 'paint', 'strict', 'content'].includes(s))
	);
	}

Which is used here to determine the popover's boundary :

components/src/popover/use-popover-position.ts

Lines 91 to 97 in 7ff86dc

	const { containingBlock, boundary } = findUpUntilMultiple({
	startElement: popover,
	tests: {
	containingBlock: isContainingBlock,
	boundary: (element: HTMLElement) => isContainingBlock(element) || isBoundary(element),
	},
	});

Looking at the git blame, the change to treat containerType != 'normal' as a "containing block" was added in this PR:
#2283. That PR does note that at the time there was no real need for this change, just an attempt to get ahead of needing to support container queries, and that there's no tests for this functionality.

If I manually edit my local copy of cloudscape in my node_modules to comment out this line, I'm seeing the popover position work properly:

components/src/internal/utils/dom.ts

Line 13 in 7ff86dc

(!!computedStyle.containerType && computedStyle.containerType !== 'normal') ||

[YueyingLu]

Hey @bmv437
thanks for reaching out and your investigation. Our team will work on it and keep you updated.

[avinashbot]

Thanks for opening the bug report - I can reproduce this in Chrome and Firefox (but not Safari). The original PR was necessary because a query container is supposed to create a new containing block context and affect fixed positioning for child components. But it looks like this behavior was silently changed at some point (w3c/csswg-drafts#10544) after the PR was released, and updated only in Chrome and Firefox. So it looks like we'll have to do some browser/CSS support checks before applying this logic.

[bmv437]

Thanks for looking into it. Very cool find around the behavior changing in Chrome/Firefox but the MDN docs not reflecting that.

I did some additional research into similar popover implementations, and found this:
https://floating-ui.com/

Internally, they have a very similar isContainingBlock implementation with some additional checks:
https://github.com/floating-ui/floating-ui/blob/b9ad108d9b0257fe1d7d25a3b187fd5189062b9a/packages/utils/src/dom.ts#L86-L113

And they also have overflow element detection:
https://github.com/floating-ui/floating-ui/blob/master/packages/utils/src/dom.ts#L64-L70

Which seems similar to the isBoundary function use by the popover hook, which could be enhanced with their logic:

components/src/popover/use-popover-position.ts

Lines 253 to 256 in 673f781

	function isBoundary(element: HTMLElement) {
	const computedStyle = getComputedStyle(element);
	return !!computedStyle.clipPath && computedStyle.clipPath !== 'none';
	}

[pan-kot]

Hey @bmv437,

Thanks for your research! Our team is still working on the mitigation. Meanwhile, you might be able to use the workaround by setting the contain: layout for your container. This forces creation of the new containing block and works consistently across Chrome, Firefox, and Safari.