Flatpickr fails when rendered inside a different window/document

I am using react-flatpickr in a React application, which internally uses flatpickr.

Our application supports rendering React components into a separate browser window using React Portals. The new window is created using window.open(), and the React component containing react-flatpickr is rendered into the new window's document.

Conceptually:

const newWindow = window.open(...);

createPortal(
    <Flatpickr ... />,
    newWindow.document.body
);

When react-flatpickr / flatpickr is rendered into this new window, Flatpickr fails with an error similar to:

this._flatPickr is not defined

Root cause

After debugging, I noticed that Flatpickr performs checks using global DOM constructors such as Node and HTMLElement.

These checks can become problematic when the component is rendered into a different browser window because each window has its own set of DOM globals.

For example:

window.Node !== newWindow.Node
window.HTMLElement !== newWindow.HTMLElement

As a result, an element created in the detached window may not pass checks such as:

element instanceof Node
element instanceof HTMLElement

when Node / HTMLElement refer to the constructors from the main window.

This is particularly relevant for React applications using portals across browser windows, where the React component is part of the same application but its DOM elements belong to a different Document.

Possible solution

Where possible, the relevant DOM type checks could use DOM properties rather than relying on global constructors such as Node and HTMLElement.

For example, an element check could use:

element?.nodeType === 1

This avoids the cross-window instanceof issue because nodeType is a property of the DOM node itself and does not depend on which window the Node or HTMLElement constructor comes from.

There may be other appropriate DOM property-based checks depending on the specific use case.

Request

Could Flatpickr consider making these DOM type checks cross-window/document aware?

I encountered this issue through react-flatpickr, but the underlying problem appears to be in Flatpickr's DOM type checks rather than in the React wrapper itself.

I have also looked into a possible fix and would be happy to submit a PR if this approach is acceptable.