The final space is `nbsp` (ascii 160), internal spaces are ascii 20 about draft-js HOT 27 CLOSED

Hmm, this doesn't repro for me. You've typed a, ,b, correct? I'm not sure why there would be an  there as well.

from draft-js.

There is a space after the b and that's the one that comes out as the incorrect ascii code. I'll see if I can make a tester tonight.

from draft-js.

Ah, so you typed a, ,b, ? And the two spaces are not the same character?

from draft-js.

exactly

from draft-js.

Which browser and OS?

from draft-js.

chrome 48.0.2564.109, OS X 10.11.2,

If it isn't reproducing elsewhere, perhaps it's a weird artifact of how I was using the control.

from draft-js.

Are you able to determine whether the space bar character insertions are occurring via editOnBeforeInput?

from draft-js.

@rcoh just wanted to follow up on this. I haven't seen this issue before, but I'd certainly like to fix it if it's widespread.

from draft-js.

@hellendag I think I'm seeing the same thing here. Chrome 48.0.2564.116 (64-bit), OSX 10.11.2. The last space is an &nbsp for me as well.

EDIT:
Also tested in Safari, just in case. Not seeing the issue. Probably just Chrome.

from draft-js.

You didn't type that with an option+spacebar, right? Just regular spaces?

from draft-js.

Yes, just regular spaces.

from draft-js.

If you add more spaces, does it add more   characters? Or does that one continue to stick to the end of the text node?

Also, are you using any Chrome extensions?

from draft-js.

It doesn't add more   characters if I add more spaces, that one continues to stick to the end of the node, yes.

I am (quite a few), but I disabled all of them, shut Chrome down and retested. Same thing.

from draft-js.

Strange. Are you seeing the same thing on draftjs.org, and on Facebook comments as well?

from draft-js.

Tested. No, I'm not seeing it. Tested on the examples from the repo, they work fine as well. Wonder what it is that's going wrong here. If it's something on my end, I'll test with a fresh copy and then go from there (tomorrow, seeing as it's night here in France). Wonder if it's Flux (alt, updating the editorState from a Store) - but I can't see why.

from draft-js.

Hmm, possibly Flux. Not sure if you saw this, but it has come up a handful of times within FB: http://facebook.github.io/draft-js/docs/advanced-topics-issues-and-pitfalls.html#delayed-state-updates

from draft-js.

I was also using Redux, so that seems like a possibility.

On Wed, Mar 2, 2016 at 3:49 PM Isaac Salier-Hellendag <
[email protected]> wrote:

Hmm, possibly Flux. Not sure if you saw this, but it has come up a handful
of times within FB:
http://facebook.github.io/draft-js/docs/advanced-topics-issues-and-pitfalls.html#delayed-state-updates

—
Reply to this email directly or view it on GitHub
#74 (comment).

from draft-js.

@hellendag Hi again! Just tested with a clean component - from scratch, no flux, root-level component, instant initialisation, and I'm still getting that   at the end. If there are any more clues I can provide, give me a sign.

@rcoh have you tried using your function to cleanup text while a user is typing? I was able to use it and get the whole text of the Editor's state, and now looking into implementing it on the typed text, to get rid of the   on the fly.

The issue it creates for me is that, when I delete a line using option+backspace, the caret jumps quite a bit and doesn't stop at the space, but rather right et the end of the last word in the sentence. After that, I need to press space twice to get it to insert a normal space (and sometimes when I press space it gets all confused and jumps before the last letter of a word - even on a clean, new editor).

EDIT:
It does insert multiple   when I press space twice.

EDIT 2:
Wrapping the Editor in a <pre/> tag fixes the issue. The alt - Flux implementation also seems to function without a problem.

from draft-js.

@MindRave In fact, only white-space: pre is needed to fix the issue :)

from draft-js.

@Calyhre indeed and thank you for the pointer! I ended up going with pre-wrap in the end, that way the text wraps normally. ;)

from draft-js.

Wrapping the editor with a pre tag also fixed an issue I was having when setting the content of the editor with a space at the end, e.g jonathanmv . The space was not being taking into account when focusing the editor; the caret was next to the v instead of being after the space.

from draft-js.

If you're including https://github.com/facebook/draft-js/blob/master/src/component/base/DraftEditor.css, you shouldn't need any of this. white-space: pre-wrap is applied by default.

from draft-js.

I'm thinking I should go ahead and include whiteSpace: 'pre-wrap' in a style object directly within the JS, so that this doesn't happen anymore.

from draft-js.

@hellendag That is probably a good idea. Quite a few people (such as myself) will either choose to not include the styles in order to write their own, or simply forget to include them. Another solution would be pointing it out in the doc ("Issues and pitfalls" section?) but including it directly in the JS sounds better.

That said, thank you again for your time and support!

from draft-js.

I'm about to add it to the doc now. :)

To clarify, the right thing to do here is to run a build step, then use the resulting Draft.css resource.

You're welcome! :)

from draft-js.

Closing because there is a resolution with Draft.css.

from draft-js.

I am running into this issue myself....I am forced to overwrite styles for block public-DraftStyleDefault-block to white-space: nowrap to force the editor to behave as single line text input. If I use pre-wrap or pre the block wraps into multi-line...

If I use nowrap the block does not wrap but Undo stack is all messed up...because of the white space   issues...

The defect is around the conditional check in editOnInput.js

if (domText === modelText) { return; }

with nowrap , when multiple consecutive white space is entered into editor, dataText and modelText will have both %20 and %A0 encodings in it. %A0 is for   - but they will not match...

example for string "x " is see dataText having "x%20%A0" and modelText having "x%A0%20"

when these values do not match (and they should) the undo stack gets completely out of wack....

Using nowrap is the only way I know to prevent the block wrapping as text is typed...unless you can suggest an alternative solution...this is a showstopper issue for me as my primary objective is to provide a draftjs replacement for ordinary text input - I need to force single line....

Any idea how to make it work?

from draft-js.