reproductible also on fiddle https://jsfiddle.net/pextgbsh/2/

So it looks like that if i set `white-space: nowrap` i can skip the insertion of the newline in the textarea. What to me looks wrong is that what normally was a softwrap, now become and hard wrap with a newline in the text.

Tested in chrome # 57.0.2987.110 and Canary #59.0.3046.0 on Mac 10.12.3 and not able to reproduce the issue.Please find the screen cast for your reference.

@ andreabogazzi79: Could you please let me know if i have missed anything and if possible, please create a new profile without extensions and apps.Recheck once and let us know the observation of the issue which would help us to triage the issue further.

Thanks in Advance.

Deleted: 702926.mp4 1009 KB

	702926.mp4 1009 KB View Download

So maybe i explaine myself wrong. You have to open the console to see the output of the event, but then you have to type in the small textarea.

I inserted as a step to refresh the test case because when loaded the focus in on textarea automaticaly, so you just type something and it will go in textarea.

in the gif i posted, i first press space, and i get 2 events, then i press a and i get 1 event ( correct ) then i press space again and i get 2 events.

My understanding is that the softwrap happening in the very narrow textarea is causing an extra input with a newline.

Deleted: preview.gif 205 KB

	preview.gif 205 KB View Download

I can confirm Andrea's findings, that his jsfiddle will cause multiple events to be fired just by pressing spacebar once you find the little text selection cursor and select the text area.  On Chromium 57.0.2987.110 I get first one event and then two events for each keystroke afterwards.  One Chromium 56.0.2924.87 I only get one event per keystroke.

Confirmed.
One with data:" ", another is data:null.

i always get the newline, \n . how do you get data null? at what property of event are you referring to?

Chong is this intended behavior? I imagine it is and the original site now needs to look at the type of the input event right?

the event is still of type 'input' to me looks identical to the real one.
input event does not carry data on what has been input by user.

Bisect points to https://codereview.chromium.org/2618613004, kojii@ can you take a look?

More Info:
We fire one 'input' event per EditCommand, and the issue here seems to be that we are applying two EditCommands within a single user action (Which might cause some confusion).
e.g. The user will have to press 'undo' twice to recover to the previous state.

Do we want to combine the line-break and space into a single EditCommand?

i read the bisect commit description.

my personal opinion is that the change is wrong.

The necessity of displaying a character or a caret in a particular position should not interfer with text content.

Here we are not talking about a developer confused by a double event ( i admit this is my case ), we are talking about input in a textarea 'Hello world' and retrieving from textarea.value 'Hello\n world'.

feels incorrect.

pressing backspace does not remove both chars.

after the newline insertion the linebreak char is a normal char of my text and is not distinguible by what i input.

if you enlarge textarea with mouse the lines do not unwrap anymore.

Despite your opinion about the change, i hope i explained you with best details i could.

Thank you for the feedback, this is really appreciated.

#14: this is where Blink corrects user inputs; in OpenOffice or MS Word, when user typed "teh", the document will have "the". When user hit TAB key at the beginning of a line, the document will have indent set. These are correct as far as it's what user expects. I'd like this discussion whether the behavior matches use cases and expectations, rather than "what is correct".

I played with a modified script on Android:
http://output.jsbin.com/lupumuj
learned that when Android keyboard collects spelling, it fires one 'input' event, so we might already have the capability to do this.

The other option is to disable the behavior when the width of inputs is less than one space, because in such case the behavior isn't really useful.

Probably as suggested in #13, combining the line-break and space into a single EditCommand, or do whatever Android keyboard does, looks more consistent.

chongz@, is this possible?

#15: is not the same thing. the textarea has the same behaviour even when autocapitalize, autocorrect, autocomplete, and spellcheck are off. Is an hardcoded behavour that is not deactivable for now if not disabling wrapping on the textarea.

Also when android correct spelling it fires on input but you can disable the auto correct, or it fires it when you click the suggested word. Everything gets fired after a proper interaction with the IME. As far as i can tell, here this space is inserted as a `shortcut` to display the cursor in a different way.

i do not think that 13# is a way to solve it.

if the space is inserted to better display a cursor on the proper line, please modify  how the textarea component/widget display the cursor instead of trying to control the cursor movement adding text inside the component itself.

What about other unicode values for space, are those affected also?

#15: I'm not sure how Android keyboard works in this case, but to combine them into a single EditCommand we could either:
  1. Create a new EditCommand ("InsertLineBreakAndText"?), or
  2. Prepend '\n' to |data| instead of calling |insertLineBreak()|.

I don't have a strong preference, yosin@ do you have some suggestions?

Also Note:
This behavior might cause confusion to 'beforeinput' as well.
e.g. We are firing 'beforeinput' with |data == ' '|, but Blink is actually inserting '\n '.

Can i ask what is the problem with fixing textarea cursor display without adding text in the textarea value?

Any impediment for a proper fix?

yosin@:
#17: I don't have strong preference either, do you?

#18:
I think we're seeing things somehow differently that our communication isn't going well. I wish to fix the communication first but don't know how. From my point of view, there's no issue in textarea cursor display, so I'm not sure how to answer to you.

I prefer option 2 in #17, "Prepend '\n' to |data| instead of calling |insertLineBreak()|" with following reasons:
 1. It is easier to implement than option #1, introducing "InsertLineBreakAndText"
 2. JS can handle this case in "insertText" command handler which can have newline in input string in other cases.
 3. It seems we have too many commands in "beforeinput"

#18:
I m sorry i m not able to explain my strong opinion in a correct way.

Reading the patch file is clear that the newline is inserted for a visual behaviour. Textarea wrap text on spaces. Pressing space at the start of linewrap will put the cursor for a moment in the previous line, and then it will adjust in the correct line as soon as you type something that is different from space.
This may considered a non perfect behaviour for an user.

I have strong opinion that this should not be fixed modifying the text the user has input.

The textarea value represent what the user writes and should not be modified just to avoid the cursor jump from a line to another. The new behaviour of an inserted hard line is much worse for an user.

Please consider reverting that commit, not differently patching it.

What i was referring as a  better fix would be just draw the cursor in the proper line without modifying the text, i understand that it require a different approach. But this patch for me as a user and as developer  feels wrong.

I have to agree with #21. As described in #14 the idea that a user could enter 'Hello world' but on retrieving from textarea.value it returns 'Hello\n world' is terrible experience. There is no way to know if any '\n' was user inputed or secretly inputed by the browser.

User input in a textarea should always match the textarea.value and I'm unclear why there is resistance to that.

#21/22: I think I understand what you're trying to say, but I don't see you understand what I was trying to say, and I'm having difficulty to explain better. The line breaker is working as designed, in the same way as other browsers and major word processors, there's no problem there.

Either way, this issue is about event issue, please comment on issue 76113. It'd be helpful to describe what issues users would see, so that we can come up with ideas.

#20: Thank you for your comment, it looks like doing so solves #0 and #22.

Well firefox and ie do not insert a new line break, nor do ms word or writer from libreoffice. If i do not presse enter or shift enter, i do not get a new line.
The double firing of event is completely a minor issue.
Since i understood the new line insertion, i m very worried about that.

I checked also the original bug, the 76113, and i understood good i think.
You want to keep the cursor in the wrapped line, i do not think you should do it inserting linebreaks, but rather fixing how the textarea render the cursor.

#26: Sounds like a different issue, this issue and issue 76113 does not insert non-breaking space. Could you file a separate bug, hopefully with repro steps so that we could narrow it down?

#25: Sorry for my English skill, it looks like my previous comment didn't work. Let me try again:
1. We will be working on double-event issue by following #20. Thank you for reporting this, and we hope to solve the problem you encountered.
2. If you see any other cases where you hit problems, could you please comment on issue 76113 or open a new issue?
3. Your last paragraph of #25 doesn't match to my understanding and I'm not very clear what you're suggesting, but issue 76113 is more appropriate to discuss suggestions.
I hope this time works, but please feel free to comment here if this isn't still clear.

ok i will move on the old issue 76113. i will copy paste some comments from here.

Given the comments above, and given I'm unlikely to find time to work on this in this milestone.

Hello i come back on this issue adding a new point of view.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/textarea

textarea has a wrap attribute that is set to default to Soft.
Reading the information on MDN looks like that soft says:
`soft: The browser ensures that all line breaks in the value consist of a CR+LF pair, but does not insert any additional line breaks.`

Adding a newline to wrap the cursor is not violating the default behaviour of soft attribute?

Regards, Andrea

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I do think my last comment still apply.
Is a weird bug that should be fixed