Looks like the bug tracker converted double blank lines in "bad" example (Chrome 70) to single blank lines, hiding what I am reporting.

The bad case (Chrome 70) innerText is like this:

---
#aqm-editor.innerText
---
1
2
[ blank line 1 - right ]
[ another blank line - the bug ]
3
[ blank line 1 - right ]
[ another blank line - the bug ]
4
5
6
---

I'm also attaching all the data points as a .txt file - please see that, it has the innerText values exactly as we get them from Chrome (both bad and good cases).

Deleted: Chrome 70 extra new lines in innerText.txt 2.6 KB

Chrome 70 extra new lines in innerText.txt 2.6 KB View Download

PS:

Two blank lines in editable content turn into four blank lines in editor.innerText.

Three blank lines turn into six.

It doesn't seem specific to WebView since reporter is talking about Chrome on Android. We prefer to have WebView component if it can't repro in Chrome. Removing WebView component.

Might be  bug 899588 .

@kmansoft: Could you please provide sample URL, apk file to test this issue from our end. From comment#6 this seems to be same as  issue 899588 , could you please check and confirm. Please provide other OS behavior as well.

Thanks!

Hi,

I don't have a sample URL because this is inside a native (Java) Android app.

But I have provided exact HTML snippets that you can use to reproduce.

We use WebView and as we all know it's Chrome behind the scenes (since Android 7.0 if I'm not mistaken).

I checked #899588 and yes it looks like same exact issue:

- A single blank line (it says "tap enter twice which creates a single blank line encoded as <div><br></div> as expected")

- And yet editable.innerText has two empty lines not one

The reporter in #899588 also checked it against Chrome 69 - where according to him the issue did not occur. And so it must be new in 70 I think.

Last but not least, it says in #899588:

---
Mark WontFix since this is as expected.
Since M70, Element#innerText follows the spec[1].

Note: Due by the spec bug, we'll revert M70 and M71 to M69 behavior.
---

So you guys have already decided to revert your change in 70 (and you know what change in 70 it was, wrong change which followed a buggy spec?) although that issue is still marked WontFix.

Any plans to include the fix in a 70 update? Would be great since this will affect many apps and web sites that use content editables.

Thank you for providing more feedback. Adding the requester to the cc list.

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

@ Reporter: As per comment 5 in  Issue 899588 , dev is reverting M70 and M71 to  M69 behavior and M72 will have Fixed behavior .Could you please check this issue in latest chrome canary ?

cc'ing yosin@ from  Issue 899588  for further inputs on this.

Thanks!

Re: canary

I don't know how to make Android use Canary Chrome as WebView (maybe a setting in Developer Options?)

But:

I just tried 70.0.3538.110 on Windows which is newer than the versions in this bug report (Android WebView / Chrome 70.0.3538.80) and in #899588 (70.0.3538.77).

The bug appears fixed in 70.0.3538.110.

It also appears fixed in Chrome Beta 71.0.3578.62.

It is broken in Chrome Canary 72.0.3619.0.

I'm attaching a simple test file.

Question about Chrome 72:

Is the planned "fixed" behavior any different (again?) from what we have in Chrome 69 and below, the "before the bug" (and "all other browsers")?

I understand that there is an ongoing process where the spec is being fixed as you implement it (and discover than the new implementation breaks apps and so the spec is broken and needs to be fixed too)? I see that this happened with tabs in innerText from tables.

Please don't break this again ("break" in terms of "works noticeably different from how it worked before") in Chrome 72.

Our users expect their edited text to save and reload exactly how they entered it and how it appeared during editing. Single blank lines preserved as such, double, triple blank lines preserved as such, etc.

Deleted: ContentEditable.html 225 bytes

ContentEditable.html 225 bytes View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

Just tried Chrome Beta 71.0.3578.64 on Android 8.

( yes selecting "which Chrome to use for WebView" is in Developer Options )

The issue is not there in 71.0.3578.64.

Mark WontFix since innerText emits two newline characters for <div><br></div> as the spec[1].

See https://jsfiddle.net/23kqxyoz/1/

[1] https://html.spec.whatwg.org/multipage/dom.html#the-innertext-idl-attribute.

This means that editing is not WYSIWYG anymore.

A user may enter a single blank line - represented by <div><br></div>

But innerText will now return something entirely different - two blank line (three '\n', one for the previous line let's say it's not empty, two for the blank line).

So the user will be entering one thing (text a / one blank line / text b) and getting something else saved (two blank lines instead of one between a and b).

This is really really bad.

If this is according to the spec - please consider fixing the spec as you did recently for innerText in tables / td's.