1615890 - innerText doesn't return some characters which textContent does return

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, enhancement, P3)

Description

[Pim Blokland]

Attachment: file that reports length=2 in Firefox, but length=3 in Chrome

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.5

Steps to reproduce:

If a text in a webpage contains any of a certain set of non-spacing characters, such as U+061C, U+0200E, U+200F, U+202A, U+202B etc., the reported innerText does not match the reported textContent in JavaScript.

Actual results:

When the content of a HTML element is, for example,
(‎)
the element's reported innerText in JavaScript is "()" with the U+200E missing; the length is 2.
JavaScript's textContent on the other hand does return the U+200E correctly.

Expected results:

As far as I'm aware, there should be no difference between innerText and textContent in this regards.
In the Chrome browser, there isn't: both innerText and textContent do return the U+200E in the example.
So although I'm not sure this is actually a bug, at the very least it's a browser incompatibility problem.

Comment 1

[Pim Blokland]

I meant (‎) for a HTML element content, of course.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Need to check what the spec says about this (or is there something missing from the spec)

Comment 3

[Mats Palmgren (inactive)]

As far as I'm aware, there should be no difference between innerText and textContent in this regards.

innerText is supposed to return the "rendered text" and is intentionally not the same as textContent, which returns the text content as is. The only time when they return the same value is when the node isn't rendered at all, e.g. display:none. See https://github.com/rocallahan/innerText-spec and https://github.com/whatwg/html/issues/465 and https://github.com/whatwg/compat/issues/5 for background.

None of the mentioned characters are rendered so they should not be included in innerText IMO.
Chrome's implementation is known to be buggy: https://bugs.chromium.org/p/chromium/issues/detail?id=573309

Comment 4

[Henri Sivonen (:hsivonen)]

Test edited to work in IE:
https://software.hixie.ch/utilities/js/live-dom-viewer/saved/7775

This is originally an IE API, and IE11 says 3.