Repository navigation
Conversation
positionCalendar() measured scroll offset/viewport size/input bounds unconditionally from the local window, while calendar elements are created via createElement()'s doc() which may resolve to window.top when embedded cross-realm (e.g. inside an iframe). When appendTo points at a different realm than the input, this mismatch produced wrong (including negative) top/left/right values. Now derives the render window/document from the actual resolved appendTo target and translates the input's bounding rect into that realm via window.frameElement when they differ. Also binds the outside-click-to-close listener on the appendTo target's document in addition to the local one, since clicks in a different-realm calendar never reached a listener bound only locally.
colinli007
left a comment
colinli007
left a comment
There was a problem hiding this comment.
Thanks for working on iframe support. I tested this branch in Chrome 154 against master,
and it does fix #3096 (library in an iframe, element in the parent page). But it also
changes a case that works today:
flatpickr loaded and used normally inside a same-origin iframe (e.g. Storybook, CMS or
block editors): getDocument() resolves window.top.document, so the calendar is created
in and mounted to the top page instead of the iframe, and mousedown inside the iframe no
longer closes it.
It also doesn't cover #3138 (library in the main window, element in an iframe or popup):
_flatpickr still returns no instance there, same as master. Minor: npm run fmt:check
fails on this branch, and the diff includes a version bump and a prepare script.
I've opened #3143 with a different approach that resolves the document from
element.ownerDocument per instance instead of window.top. It covers #3096 and #3138
without changing the same-origin iframe case; there's a full comparison table there.
Happy to hear if your setup has a case it misses.
— Colin
This branch has not been deployed
3 participants
#3096
Check and allow instantiating flatpickr in iframe context. Currently it is not possible as it directly checks against main window context. This PR adds support with backwards compatibility if in non-iframe context