I can't reproduce on Mac, will try on Windows later.

Could you confirm that, after step 6, the text undo reverted is selected, and you press space while the text is selected, correct? Or do you unselect before pressing space?

When I do it, no text is selected but rather the cursor is restored to its previous position. 

I did some more testing and found a more bullet proof way to reproduce using this very webpage.

1. Select all text from my initial report above and copy it to the clipboard
2. Paste it in the "Add a comment field" at the bottom of this page.
3. resize the textarea using the corner handle until it's wide enough to make the words "auto-wrapped" wrap after the hyphen so that "wrapped" is on the line below it.
4. Click before the "w" in wrapped so that your cursor is at the begging of that line.
5. Press space to add what should be a space char between the hyphen and the "w".

This gets the textarea into the state where a \n char is used instead of a space. call textarea.value, or simply resize the text area again to confirm that a newline char followed by your space was added instead of just a space.

Actually, after a little further testing, it doesn't seem to matter if it's a symbol. If you click to place your cursor before the first character of any line after text has wrapped and press space, chrome inserts a newline char before the space. 

Easily confirmed by resizing this textarea after clicking at the beginning of any wrapped line, pressing space, and then resizing the width of this textarea to see the visually wrapped newline no longer re-wraps, but instead gets stuck with a \n in the string value just before the index of the space.

Thank you for the confirmation.

This is a "smart" behavior we implemented in issue 76113. Since we've got so many requests for the space character to be inserted at the beginning of a line, and since lines must break after such spaces, we've learned that many word processors such as MS Word modifies documents automatically in such cases.

I'm hearing sometimes it fires unexpectedly. Since this is a heuristic solution, it'd be appreciated if you could share user cases how it can be trouble more than help.

I can see how adding a space at the beginning of a new line is a good thing, but inserting a newline char where there wasn't one before (and without the user hitting the return key) changes the actual value of the text sent to the server (or used client side) in an unexpected and uncontrollable way. This "smart" feature hurts more than it helps as there's no way for us to know if said newline char was user-entered, or added by chrome when a user simply hit space when their cursor happened to be placed before the first character in a wrapped line of text.

If anything, this "smart" feature should be optional (and disabled by default as it's not part of the HTML spec).

As for heuristics, if the user hits the return key, then it's good to assume they want the next line to start with spaces. If they don't, then it simply needs to wrap without inserting characters the user didn't type.

All other use cases lead to unexpected behavior. For example, if I'm writing in any textarea in chrome (typically a comment, like this one) that is long enough to wrap, and I notice I made a type-o on the first word on a given wrapped line, I am likely to use the arrow keys or the mouse pointer to move my cursor to the beginning of that word (which happens to be at the beginning of a line), and that may make my cursor appear on the line before. Pressing space one or more times should NEVER add a newline char as that is not what the user would ever expect to happen.

Please change that behavior back or add a switch to disable it. Since it was introduced it has become so painful to write correctly formatted forum posts. In many cases the undesired breaks are completely undetectable before pressing the 'post' button.

I concur with the several comment above that Chrome should never modify users' input, let alone silently and invisibly. Forcing hard newlines into textareas, when the user never typed them, is a gross violation of expectations.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b7c48e4a30b083b151c49018b22e54f5e6629bb2

commit b7c48e4a30b083b151c49018b22e54f5e6629bb2
Author: Koji Ishii <kojii@chromium.org>
Date: Wed Jan 10 06:45:40 2018

Limit insertion of a new line to only when after a space

This patch limits the insertion of a new line in r441848 to only
when the previous character is a space character, as an undesired
side effect was reported in issue 713969.

Bug: 713969
Change-Id: I51667c16abefe24e7fbc43060fbccce634c4b38a
Reviewed-on: https://chromium-review.googlesource.com/857776
Commit-Queue: Koji Ishii <kojii@chromium.org>
Reviewed-by: Yoshifumi Inoue <yosin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#528253}
[modify] https://crrev.com/b7c48e4a30b083b151c49018b22e54f5e6629bb2/third_party/WebKit/LayoutTests/editing/inserting/insert-space-at-start-of-wrapped-line.html
[modify] https://crrev.com/b7c48e4a30b083b151c49018b22e54f5e6629bb2/third_party/WebKit/Source/core/editing/Editor.cpp

Oh, please, can't you switch it off completely? At least optionally, using a switch? It really drives people crazy. To me it is completely natural, that adding space (or short words) at the beginning of a line might be wrapped back to the previous one. Editors should add line breaks when I do it explicitly by pressing return, and only then. It is as simple as that. Anything else is an annoyance. To try behave like Microsoft Word is IMHO not a valid argument. The 'smart' features there drives almost everyone I know crazy, too. But Microsoft was at least wise enough to allow to disable it:

https://support.office.com/en-ie/article/Choose-AutoCorrect-options-for-capitalization-spelling-and-symbols-e7433b94-f3de-4532-9dc8-b29063a96e1f

+1 for switching off completely or making it optional. The current behavior is wildly unacceptable, and half-baked fixes don't suffice. The correct approach is very simple: NEVER MODIFY USER-ENTERED TEXT WITHOUT THEIR PERMISSION. 

Another +1 for switching it off completely. If the user doesn’t hit return, they clearly don’t want a new line.

Also, I originally reported this bug when I noticed it happening after a space... so I don’t see this fix as a solution.

Please and thanks!

All browsers do modify user inputs in some ways since decades ago, it's just unnoticeable because they don't kick in when not desired.

If you could gives us specific cases in a separate issue, that'll help further discussions.

What are some examples of such modifications?

This is as specific a case as should be necessary: If a user didn't type a newline, and a newline gets added, that's not what they typed so it is wrong.

My specific use cases:

1. Comment fields where input is parsed server-side and newline chars are converted to <br/>'s when printing the input. If fantom \n's appear in the input that are indistinquishable from the actual \n's created when a user hits return, we end up having what appears to be random <br/>'s appear in the comments when they're displayed (even though the user never pressed return in the position where).

2. Markdown (or other syntax) input where multiple sequential spaces have meaning. If chrome inserts \n's inbetween some of those spaces, they effectively change the input the user thought they had submitted into something with a different meaning.

Honestly, I can't think of a single scenario where it would be helpful to randomly insert a hidden \n char when the user never pressed return to explicitly start a new line. If the user wanted the line of text below another line of text to explicitly start with a new line and a space, they can simply hit return, space. This is obvious. In what possible scenario would anyone ever want to have a newline char be secretly added when they never hit the return key?

 Issue 807373  has been merged into this issue.

I concur with several comments above to switching off this completely. And wanted to know if there is any timeline for this?

Thanks a lot!