Correctly handle different javascript realms/documents

[edave64]

In JavaScript, multiple different global contexts (realms) can exist with their own classes and document (https://tc39.es/ecma262/#realm) and they can access each others objects.

These realms are created by calls to window.open or when using <iframe>s. An application I am working on enables multi-monitor support by opening multiple browser windows that are all controlled from the primary tab. And Quill does not function correctly when initialized in one of these external windows.

This can lead to very unintuitive behavior, since using the global document can lead to incorrect results and instanceof unexpectedly returning false. And because of https://bugzilla.mozilla.org/show_bug.cgi?id=1470017 in FireFox, we cannot even control what realm our initial objects are part of.

Luckily, nodes own references to their ownerDocument, which has a reference to their defaultView, making it possible to write code that survives these conditions.

This PR removes the expectation that document is the only document that can exist and fixes instanceof checks.

This requires https://github.com/slab/parchment/pull/147 to work properly.

After this is merged, I will try to expand it to supporting shadowDOM as well, most of the basics are there, but it needs some bigger Emitter changes and don't really fit here. But this does already lay some groundwork and can clarify what tests will be needed for testing Quill in non-standard contexts.

[edave64]

I've marked this as open, since it can already be reviewed and tested, but keep in mind that the E2E test will fail in Firefox until parchment is updated. (https://github.com/slab/parchment/pull/147)

For local testing, the package.json can be modified to load parchment from a local checkout of that branch.

[jtomaszewski]

This probably would finally let quill be used in SSR-based environments ( https://github.com/zenoamaro/react-quill/issues/919 ).

Any idea if @slab is still maintaining this project? Wondering if it should be forked instead.

[edave64]

@jtomaszewski No idea to both. I've never worked with SSR and the changes it requires. Honestly the entire concept of doing that with a WYSIWYG-Editor scares me a bit ^^'

It definitly has some overlap with shadow DOM support.

If there are changes that need to be done to get this merged, I'd be willing to make them.

[jtomaszewski]

Currently this package can't be imported on SSR because it blows up with document is not found. One has to use dynamic import()s in order to use it.

I wouldn't be surprised if your changes fixed the references to objects such as document that don't exist in server-based environments.