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?
On Windows systems with performance problems or when performing expensive operations in Draft (such as with a decorator) pressing the enter key will sometimes immediately revert itself. In the following hithere <enter> is quickly typed but after pressing <enter> the new line is reverted and the e is added:
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/.
While the image is not from core Draft, it is possible to reproduce on https://facebook.github.io/draft-js but significantly more difficulty. The image repros it easily because there is a good amount of processing happening on change which slows IE perf down enough to hit this issue.
What is the expected behavior?
The <enter> will not revert itself.
Which versions of Draft.js, and which browser / OS are affected by this issue? Did this work in previous versions of Draft.js?
IE 11, Draft 0.10
@max-winderbaum did the investigation on our side and discovered the root cause:
Type a.
It's a simple character. Native insertion is allowed onBeforeInput
Native insertion does a setImmediate() call to update the state because IE won't fire the input event (see below)
Normal browsers fire the input event which clears the _pendingStateFromBeforeInput and when the setImmediate() fires it noops
IE relies on the setImmediate() completing to rectify the DOM change with its internal state
Before the setImmediate() fires, the user presses <enter>. This action is not a "native insertion" event and the state is updated immediately.
The setImmediate() fires and the content is replaced with the state before the <enter> was pressed
This is fixed by textioHQ#24 in our branch. My plan is to port this change to facebook/draft-js to make our solution to #989 easier to merge.
The text was updated successfully, but these errors were encountered:
Do you want to request a feature or report a bug?
Bug
What is the current behavior?
On Windows systems with performance problems or when performing expensive operations in Draft (such as with a decorator) pressing the enter key will sometimes immediately revert itself. In the following
hithere <enter>
is quickly typed but after pressing<enter>
the new line is reverted and thee
is added: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/.
While the image is not from core Draft, it is possible to reproduce on https://facebook.github.io/draft-js but significantly more difficulty. The image repros it easily because there is a good amount of processing happening on change which slows IE perf down enough to hit this issue.
What is the expected behavior?
The
<enter>
will not revert itself.Which versions of Draft.js, and which browser / OS are affected by this issue? Did this work in previous versions of Draft.js?
IE 11, Draft 0.10
@max-winderbaum did the investigation on our side and discovered the root cause:
a
.onBeforeInput
setImmediate()
call to update the state because IE won't fire theinput
event (see below)input
event which clears the_pendingStateFromBeforeInput
and when thesetImmediate()
fires it noopssetImmediate()
completing to rectify the DOM change with its internal statesetImmediate()
fires, the user presses<enter>
. This action is not a "native insertion" event and the state is updated immediately.setImmediate()
fires and the content is replaced with the state before the<enter>
was pressedThis is fixed by textioHQ#24 in our branch. My plan is to port this change to facebook/draft-js to make our solution to #989 easier to merge.
The text was updated successfully, but these errors were encountered: