Safari and Firefox has the same behavior.

This behavior is defined by the HTML standard. The behavior without display:none is a bug according to it.

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

Please use textContent or defaultValue or value setter instead of innerText setter.

Thanks very much.

Can I think that: with display:block, the browser operation is to keep the old HTML page compatible?

> with display:block, the browser operation is to keep the old HTML page compatible?

Mainly for IE-compatibility.
Firefox inserts a <br> even with display:block.  So we can guess there are no many web site relying on this behavior.

I see. Thanks.

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

commit e8cf8925a1f9bf3fc2b428b56e8565ef2c008c3a
Author: tkent <tkent@chromium.org>
Date: Thu Mar 30 08:52:46 2017

[innerText] Add more tests to setter.html.

- Test WebKit's quirky behavior
- Test that TEXTAREA isn't special

BUG= 705478 

Review-Url: https://codereview.chromium.org/2786903002
Cr-Commit-Position: refs/heads/master@{#460701}

[modify] https://crrev.com/e8cf8925a1f9bf3fc2b428b56e8565ef2c008c3a/third_party/WebKit/LayoutTests/external/wpt/innerText/setter-expected.txt
[modify] https://crrev.com/e8cf8925a1f9bf3fc2b428b56e8565ef2c008c3a/third_party/WebKit/LayoutTests/external/wpt/innerText/setter-tests.js
[modify] https://crrev.com/e8cf8925a1f9bf3fc2b428b56e8565ef2c008c3a/third_party/WebKit/LayoutTests/external/wpt/innerText/setter.html

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

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

commit fa583784527c3c1575f1145d31c79c6733176d38
Author: Sunny <ratsunny@gmail.com>
Date: Mon Oct 22 05:50:45 2018

Align some set innerText behavior with standard

According to spec[1], when a string starts with CR/LF set as innerText,
the first child node should not be an empty text node. So we adjust the
logic in HTMLElement::TextToFragment to make sure it follows the spec.

Besides, same in spec[1], there is no special procedure for setting
innerText when the element is being rendered and styled as preserving
new line, so corresponding code was removed in this commit.

15 failed wpt tests could be passed after this change.

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

Bug: 573309,  705478 
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng;luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I6765601a14c2e95cec3841e084046da79aca065c
Reviewed-on: https://chromium-review.googlesource.com/c/1266728
Reviewed-by: Kent Tamura <tkent@chromium.org>
Commit-Queue: Kent Tamura <tkent@chromium.org>
Cr-Commit-Position: refs/heads/master@{#601480}
[modify] https://crrev.com/fa583784527c3c1575f1145d31c79c6733176d38/third_party/WebKit/LayoutTests/external/wpt/html/dom/elements/the-innertext-idl-attribute/setter-expected.txt
[modify] https://crrev.com/fa583784527c3c1575f1145d31c79c6733176d38/third_party/blink/renderer/core/html/html_element.cc