Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

typing "<space><space>" in empty paragraph removes the whitespace #292

Closed
bantic opened this issue Jan 13, 2016 · 2 comments · Fixed by #294
Closed

typing "<space><space>" in empty paragraph removes the whitespace #292

bantic opened this issue Jan 13, 2016 · 2 comments · Fixed by #294
Assignees
Milestone

Comments

@bantic
Copy link
Collaborator

bantic commented Jan 13, 2016

On Chrome, typing two spaces in a row in an empty paragraph causes them to both be removed and the paragraph is rerendered as an empty paragraph.

bug

@bantic
Copy link
Collaborator Author

bantic commented Jan 13, 2016

Does not happen on Safari 9.0.2 or Firefox 42.0 and 43.0.4. Observed on Chrome 48.0.2564.79 beta and 47.0.2526.106 (stable)

@bantic bantic self-assigned this Jan 13, 2016
@bantic bantic added this to the 0.8 milestone Jan 13, 2016
@bantic
Copy link
Collaborator Author

bantic commented Jan 14, 2016

This is caused when there is a listener for "DOMSubtreeModified" added to the window (even if its callback is a no-op). It's reproducible in all browsers mentioned above. It originally appeared to be isolated to Chrome because I had an extension that added the listener in question on Chrome.

Adding a DOMSubtreeModified listener changes the batching of mutation events that mobiledoc-kit's MutationObserver sees.

When no such listener is attached and a user types a space at the end of a text node, the browser replaces that space with an &nbsp; to preserve the appearance of multiple spaces in the UI. If it didn't do this, the multiple spaces in dom would appear as a single space in the UI. The editor-dom renderer already does this (see #68 and #75). The browser fires the mutation observer callback once, with 3 mutations: adding a space, removing the text node, and replacing it with a text node with a trailing &nbsp;. The mutation observer callback triggers an editor reparse, and at the moment of reparsing the correct number of spaces are in the text node.

When the listener is attached, however, the browser fires the mutation observer once for each mutation, rather than once at the end of all 3 mutations. This means the editor reparse will happen when the text node is blank, which causes it to replace the text node with a <br> cursor placeholder. At that point the final mutation that would have happened (replacing the blank text node with one with the correct spaces and a trailing &nbsp;) never happens because the text node has been removed.

To fix this we will add an explicit listener for typing a space (like we already do for <tab>) and handle it declaratively rather than letting the browser shuffle DOM around.

bantic added a commit that referenced this issue Jan 14, 2016
Refactor text expansion code to happen on keyDown of the `trigger`
rather than using setTimeout and reparse

Fixes #292
bantic added a commit that referenced this issue Jan 14, 2016
Refactor text expansion code to happen on keyDown of the `trigger`
rather than using setTimeout and reparse

Fixes #292
bantic added a commit that referenced this issue Jan 14, 2016
Refactor text expansion code to happen on keyDown of the `trigger`
rather than using setTimeout and reparse

Fixes #292
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant