Bug 238555 – HTMLElement.innerText should return the content of a clipped box

• Component: DOM
• Status: NEW

[alan]

Created attachment 456128 [details]
test case

I think we fail at interpreting "being rendered" properly.

https://html.spec.whatwg.org/multipage/dom.html#the-innertext-idl-attribute says that innerText returns a DOMString representing the rendered text content of an element if it is being rendered.
while "An element is being rendered if it has any associated CSS layout boxes, SVG layout boxes, or some equivalent in other styling languages" (https://html.spec.whatwg.org/multipage/rendering.html#being-rendered)
So I would think clipped content is still considered "being rendered" as we compute geometry/create box for such content.

[alan]

innerText calls TextIterator::handleTextNode() which early returns when the content is clipped:
"if (m_fullyClippedStack.top() && !m_behaviors.contains(TextIteratorBehavior::IgnoresStyleVisibility))"

[Ryosuke Niwa]

Hm... skipping clipped content stuff comes from this change:
https://github.com/WebKit/WebKit/commit/55e9335cacf138ba817ca25d71e3d8ae66d1ced6

I guess this is really for find so we could add a new TextIterator behavior to not ignore clipped contents and use it in innerText and other places where appropriate.

[Ryosuke Niwa]

Alternatively, we could re-implement innerText as the spec says. There is no reason it has to use innerText if there is a clear spec text which specifies the behavior since TextIterator is used for all sorts of other features like copy & paste, etc... and has a lot of quirky behaviors.

[Radar WebKit Bug Importer]

<rdar://problem/91356685>

[Darin Adler]

TextIteratorBehavior::IgnoresStyleVisibility lets us do this without moving off of TextIterator.

A whole new implementation of innerText is also OK.