You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 6, 2023. It is now read-only.
Do you want to request a feature or report a bug?
Bug
What is the current behavior?
When creating a React application using Meteor and DraftJs, trying to render the Editor and make any change will cause the checks for node instanceof Element and node instanceof HTMLElement to return false and prevent the use of draft.js.
Since Meteor compiles scripts and import them in the current window, draft.js Element is the global Element, however, the obtained node by ReactDOM.findNode was created using the iframe's Element constructor. Instanceof implementation suggest using this line rather than accessible Element directly.
This is consistent across the tested browser and is probably caused by the fact that draft.js uses the global Element, which is loaded as the global window Element when the script is first imported, rather than the current window Element.
This was also tested using a standard iFrame with injecting HTML, an iFrame with portals and react-frame-component.
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. You can use this jsfiddle to get started: https://jsfiddle.net/stopachka/m6z0xn4r/.
When doing this, the following error is caused in the console when writing in the editor :
What is the expected behavior?
Draft.js should probably not rely on the Element global or the window/document globals for its code. In this case, draft.js should behave like usual when added inside an iframe.
Maybe replace this with an implementation similar to lodash's isElement could also fix this issue, but it has been stated before that iframes are unlikely to be supported in #527. This is also specific to meteor's compiling, but may cause problem for other js compiled and minifiers.
Which versions of Draft.js, and which browser / OS are affected by this issue? Did this work in previous versions of Draft.js?
Tested in version 0.10.5,
Tested with Chrome, Firefox and Microsoft Edge, all latest versions.
I had not tested it with earlier version of draft-js as NPM always install the latest version.
I also tried to implement to solution proposed in PR #765, but it seems the selection is not registered.
The text was updated successfully, but these errors were encountered:
Hi @Minivera -
I don't know yet if Draft.js and React will fully support selection and editing behavior within iframes, via #765 and also facebook/react#9184
The most correct thing is, like you suggested, to "not rely on the Element global or the window/document globals for its code" but we have not had this come up often as a problem and making the change could add complexity to Draft and/or React.
This seems like potentially a duplicate of #527 or is there some part of this error that isn't related to using an iframe? I haven't used Meteor so it could be helpful if you explain more about how that is affecting the situation.
IFrames are a very specific behavior of the application I am building and I unfortunately cannot remove it, I try to work around it as I understand this is an edge case both for React and Draft.js.
I first thought this was a Meteor issue since Meteor dynamically imports packages in a compiled js file. This means that script files could not be imported inside the iframe's code without creating a new application. I though this might have been a specific case as something like this worked when I tested with a non-meteor application, but failed in a meteor application. While Meteor is part of my error, the core of the issue is most likely a duplicate of #527.
I am far from the level of any facebook programmer, but I have changed all instances of document, window or global to something similar to :
var doc = node.ownerDocument.documentElement || document;
Not having the || document caused the unit tests to fail, something the solution in #765 did cause on my end when running npm run test. With the onSelect plugin I linked in my second comment, this did the trick, though I may still run into bugs as I test further.
If I may, I will stay on my fork for now as the application must be deployed pretty soon, but do you know if a solution similar to the PR #765 is likely to be implement in the near future?
Do you want to request a feature or report a bug?
Bug
What is the current behavior?
When creating a React application using Meteor and DraftJs, trying to render the Editor and make any change will cause the checks for
node instanceof Element
andnode instanceof HTMLElement
to returnfalse
and prevent the use of draft.js.Since Meteor compiles scripts and import them in the current window, draft.js
Element
is the globalElement
, however, the obtained node byReactDOM.findNode
was created using the iframe'sElement
constructor. Instanceof implementation suggest using this line rather than accessibleElement
directly.myNode instanceof myNode.ownerDocument.defaultView.SVGElement
This can be seen there for example : https://github.com/facebook/draft-js/blob/788595984da7c1e00d1071ea82b063ff87140be4/src/component/contents/DraftEditorTextNode.react.js#L84
This is consistent across the tested browser and is probably caused by the fact that draft.js uses the global
Element
, which is loaded as the global windowElement
when the script is first imported, rather than the current windowElement
.This was also tested using a standard iFrame with injecting HTML, an iFrame with portals and
react-frame-component
.If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. You can use this jsfiddle to get started: https://jsfiddle.net/stopachka/m6z0xn4r/.
When doing this, the following error is caused in the console when writing in the editor :
What is the expected behavior?
Draft.js should probably not rely on the Element global or the window/document globals for its code. In this case, draft.js should behave like usual when added inside an iframe.
Maybe replace this with an implementation similar to lodash's isElement could also fix this issue, but it has been stated before that iframes are unlikely to be supported in #527. This is also specific to meteor's compiling, but may cause problem for other js compiled and minifiers.
Which versions of Draft.js, and which browser / OS are affected by this issue? Did this work in previous versions of Draft.js?
Tested in version 0.10.5,
Tested with Chrome, Firefox and Microsoft Edge, all latest versions.
I had not tested it with earlier version of draft-js as NPM always install the latest version.
I also tried to implement to solution proposed in PR #765, but it seems the selection is not registered.
The text was updated successfully, but these errors were encountered: