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

Bug: Whitespace added at the start on focus #43

Merged
merged 4 commits into from
Sep 13, 2013

Conversation

matteoagosti
Copy link
Contributor

Sometimes a non-breaking space is added to the beginning of a block. I cannot reproduce it reliably, but it happens quite often.

@peyerluk
Copy link
Member Author

Maybe the non-breaking space is there from the beginning and just not displayed by the browser. I observed that in Chrome when logging a pasted value to the console.

@matteoagosti
Copy link
Contributor

Right now the cleaning of internals remove spaces at the beginning but not at the end of a block. If you press enter at the end of a paragraph there is the chance of non breaking spaces on the block that is getting created afterwards. The cursor, however, is moved at the beginning of the block so you don't notice the space unless you press the right arrow key. We could improve the cleaning function and prevent this.

@peyerluk
Copy link
Member Author

I can reproduce it now in chrome. If you paste something like ' word' with a space at the beginning into an empty paragraph the space is not shown. After a blur and focus it suddenly appears.

Maybe we could prevent this in 'paste' and 'split' events instead of the cleanup method.

Previously normalizeSpace assumed a parent node as
argument. Now it works also when you pass a text node
(this is the case of the paste).
@matteoagosti
Copy link
Contributor

@peyerluk I fixed the bug by running normalizeSpaces on pasted content. I agree with you that we should also think on having it for split, however I initially thought to have it on focus as it may happen the initial document contain spaces (see our test file for example 🐱 ): as focus is an immediate consequence of split the risk is of running it twice. What do you think?

@peyerluk
Copy link
Member Author

Lets try it just on focus and not on split. Then we just need to remember to always apply focus on the last possible moment. But I guess this is a good general rule anyway.

@matteoagosti
Copy link
Contributor

In addition, when overriding some specific behaviors (as an implementor) I could be sure that on focus everything gets fixed and in general you are not likely to override the focus.

My commit solves the bug so whenever you want feel free to merge.

@peyerluk
Copy link
Member Author

Don't you want to add it on focus as well before we merge?

@matteoagosti
Copy link
Contributor

It was already there, that is why the space was getting visible after blur/focus

@peyerluk
Copy link
Member Author

Hmm, then we need to do it on editable.add() as well... Or we need to remove/collapse all whitespaces except non-breaking spaces on editable.add().

@matteoagosti
Copy link
Contributor

I would add it the "add" function as you mentioned.
Lets use this pull request to solve also the issue of trailing spaces. I'll work on that ▶️

This doesn't remove spaces at the end, it just converts
the last one to make it visible. I think the strategy of not
having spaces at all in the end should go in a config
option and shouldn't be a task of normalizeSpaces.
@peyerluk
Copy link
Member Author

👍

matteoagosti added a commit that referenced this pull request Sep 13, 2013
Bug: Whitespace added at the start on focus
@matteoagosti matteoagosti merged commit c2df7fb into master Sep 13, 2013
@matteoagosti matteoagosti deleted the whitespace-on-paste branch September 13, 2013 12:16
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 this pull request may close these issues.

2 participants