Kunal8954 commented on issue #43897:
URL: https://github.com/apache/superset/issues/43897#issuecomment-5550181027
Thanks for confirming — that rules out what I described. The overflow
dropdown path only exists in horizontal mode, so scratch that.
In vertical mode both the popover and the picker mount on document.body,
so nothing should be clipping them via an ancestor's overflow. The one
zoom-sensitive thing I can find in this path is ControlPopover picking its
own placement from viewport ratios:
ControlPopover.tsx L34-47 — yRatio = rect.top / window.innerHeight,
xRatio = rect.left / window.innerWidth
L99-122 — 0.35 / 0.65 thresholds choose top/bottom/left/right or a corner
placement
Browser zoom changes window.innerHeight/innerWidth in CSS pixels, so the
same filter at the same spot can resolve to a different placement at 100%
vs 75%. And the note on L52 + L77-81 says only top/bottom/left/right get
antd's shifting, with the others explicitly called out as able to leave "an
oversized one stranded off screen".
That's a hypothesis, not a diagnosis — I can't tell which placement your
layout actually resolves to. Could you open the calendar at 100% zoom and
grab, from DevTools:
- the class on the popup wrapper (it carries the placement, e.g.
ant-picker-dropdown-placement-bottomLeft)
- its computed top/left
- whether it's a direct child of <body>
That would say whether it's mis-placed or genuinely clipped, and by what.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
