OverlayPanel and Menu positioning problem

[radu-ux]

Hello,

This is a followup discussion to this issue: primefaces/primereact#6351

After a research, I think that the problem is related to how the top and left coordinates are being calculated in both Menu and OverlayPanel components. In both cases, the utility function used is DomHandler.positionAbsolute that always takes into consideration viewport and ignores the appendTo prop that might signal the component that the consumer wants to place the element where it is actually rendered in the VDOM (passing self as value).

I was thinking that a solution might be to use DomHandler.alingOverlay, the same as for MultiSelect component, in this way the top and left coordinates will be correctly computed.

My question would be: was there any intention in using positionAbsolute rather than alignOverlay in the first place?

Existing code snippet for aligning overlay in Menu component

 const [bindOverlayListener, unbindOverlayListener] = useOverlayListener({
            target: targetRef,
            overlay: menuRef,
            listener: (event, { valid, type }) => {
                if (valid) {
                    if (context.hideOverlaysOnDocumentScrolling || type === 'outside') {
                        hide(event);
                        setFocusedOptionIndex(-1);
                    } else if (!DomHandler.isDocument(event.target)) {
                        DomHandler.absolutePosition(menuRef.current, targetRef.current, props.popupAlignment);
                    }
                }
            },
            when: visibleState
        });

Existing code snippet for aligning overlay in OverlayPanel component

    const align = () => {
        if (currentTargetRef.current && overlayRef.current) {
            DomHandler.absolutePosition(overlayRef.current, currentTargetRef.current);

            const containerOffset = DomHandler.getOffset(overlayRef.current);
            const targetOffset = DomHandler.getOffset(currentTargetRef.current);
            let arrowLeft = 0;

            if (containerOffset.left < targetOffset.left) {
                arrowLeft = targetOffset.left - containerOffset.left;
            }

            overlayRef.current.style.setProperty('--overlayArrowLeft', `${arrowLeft}px`);

            if (containerOffset.top < targetOffset.top) {
                overlayRef.current.setAttribute('data-p-overlaypanel-flipped', 'true');
                isUnstyled && DomHandler.addClass(overlayRef.current, 'p-overlaypanel-flipped');
            } else {
                overlayRef.current.setAttribute('data-p-overlaypanel-flipped', 'false');
                isUnstyled && DomHandler.removeClass(overlayRef.current, 'p-overlaypanel-flipped');
            }
        }
    };

Thank you!

[Coderxrohan]

Good analysis — your understanding of the positioning logic is correct.

In PrimeReact, DomHandler.absolutePosition was originally chosen for components like Menu and OverlayPanel mainly for predictable viewport-based positioning. These overlays historically prioritized:

1. Staying within the viewport
2. Avoiding clipping and overflow issues
3. Consistent behavior regardless of where they’re rendered

Because of that, appendTo="self" was never fully treated as a “pure VDOM positioning” signal, but more as a rendering container hint.

That said, you’re also right that this creates friction when consumers explicitly want the overlay positioned relative to its actual DOM context. Components like MultiSelect using alignOverlay show that this alternative works better when appendTo is respected.

From my perspective, the original choice was about safety and consistency, not because alignOverlay was unsuitable. With more components now supporting flexible append targets, revisiting this — or conditionally switching behavior based on appendTo — seems reasonable.

Personally, I think this is less about a bug and more about an evolving design tradeoff, and your suggestion makes sense as a potential refinement rather than a breaking change.