* Gutenberg version*
v4.2
Describe the bug
When using backspace in the editor it automatically closes spaces between the removed word and the former. It should not remove the space since it forces users to make a new space every time a word is removed.
How to reproduce the issue
The new word should have a space in front of it, but instead it continues as a part of the former word.
Proof of the issue
Thank you for the report! Noting we'll want to test this in various browsers. @exzrael may I ask your OS and browser versions for reference?
I am also experiencing this issue within Gutenberg 4.2. I'm using OS X 10.13.6 and Chrome 70.
I was just about to report the exact same issue. Persists across multiple browsers (Chrome, Firefox, Edge) on both Windows and MacOS.
Interestingly the bug behaves differently when editing words in between other words. In those cases when the remaining letter of a word is deleted, the space _after_ that word is deleted.
I created a video to demonstrate further:
Interestingly the bug behaves differently when editing words in between other words. In those cases when the remaining letter of a word is deleted, the space after that word is deleted.
Odd! Tested and confirmed with Firefox 63.0.1 and Chrome 70.0.3538.77 on macOS 10.13.6.
Issue is present on:
macOS 10.14 "Mojave"
with:
Google Chrome 70.0.3538.77
Safari 12.0
The issue is NOT present with:
Firefox 63.0.1 (which is kind of strange since @designsimply actually confirm the issue WITH Firefox 63.0.1)
Also having the same issue on Windows 10 with Chrome 70.0.3538.77. Is there a way to roll back an update as this issue really drives me mad.
Problem exists on Windows 7, Chrome 70.0.3538.77.
Problem does NOT exist on Windows 7, Firefox 62.0.2 (64-bit) (so I guess I'll be writing in Firefox for a while).
Have the same problem. MacOS Mojave and Google Chrome Version 70.0.3538.77 (Official Build) (64-bit).
In addition this problem also occurs with soft linebreaks. Add one with Shift+Enter, type a letter, remove the letter and it will remove the linebreak as well. Please fix that.
I'm also having this issue on Windows 10 and Chrome 70.0.3538.102 (Official Build) (64-bit).
Firefox 49.0 had the behavior for the words mid-sentence, but if you started typing the missing space would reappear. If you move the cursor it's lost.
Firefox 56.0 also did that, and would sometimes, but not always, do it with the final word in a paragraph. It stopped entirely while I was trying to find what why it was inconsistent, but continued doing it mid-sentence.
Firefox 63.0.1 was like the final state of 56.0. It did not appear to do it to the final word, but mid-sentence behavior persisted.
I went back and tested mid-sentence behavior in Chrome and it is also removed the space after the word, but does not add the missing space back when you start typing.
I've been unable to duplicate as-is this with WordPress 5.0 / Gutenberg Master / Twenty Nineteen or WordPress 4.9.8 / Gutenberg 4.4.0 / Twenty Seventeen - Testing in Chrome 70.0.3538.77, Chrome 70.0.3538.102, and Firefox 63.0.3 on Mac OS 10.14.
I went back and tested mid-sentence behavior in Chrome and it is also removed the space after the word, but does not add the missing space back when you start typing.
I was however able to duplicate this in Chrome, If I select a word (either by highlight, or double click) and then backspace it (But NOT when placing the cursor after the word and backspacing it), the DOM would read word1 word2
(two spaces) but the UI would show the cursor directly before word2
such like this: word1 |word2
, typing would then eat that second space and result with word1 word4word3
instead of the expected word1 word4 word3
.
Testing in Firefox 63.0.3
caused the same carrot positioning, but the space would re-appear once the word started being typed.
@dd32 Thanks for testing.
The issue was solved in #11627 a week ago and is part of 4.3 and 4.4. When pressing backspace on an uncollapsed selection, one of the surrounding spaces is indeed removed, but this is also the case in e.g. TinyMCE in my testing. The only difference seems to be that the caret ends up after the space instead of before. Since the main issue was solved here, I'll close this and create a new one for the caret position being off.
Most helpful comment
I am also experiencing this issue within Gutenberg 4.2. I'm using OS X 10.13.6 and Chrome 70.