Bug 237330 – A text node longer than 65,535 characters following another text node is invisible in a scrolling context

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Jed Fox]

Created attachment 453507 [details]
HTML file with sample code that does and does not trigger the bug

I’ve narrowed the reproduction down to the following specific requirements:

- A parent node must have `overflow: auto` (not necessarily the immediate parent of the text node)
- The text node must not be the first node on its line (taking word wrapping into account)
- The text node must have at least 65,536 characters (I tested with the ASCII 0, although it seems that other characters can be present)

Encountered in the wild: https://github.com/facebook/jsx/pull/136#issuecomment-1055288199

Reproduced on STP Release 140 (Safari 15.4, WebKit 17614.1.1.5) and WebKit r290647 on macOS 12.2.1 (21D62)

[Radar WebKit Bug Importer]

<rdar://problem/89645522>

[alan]

Created attachment 453545 [details]
Test reduction (just a slight iteration on the test above)

[alan]

This is most likely caused by our 64K RenderText split.

[alan]

Yeah, it must be it. If some of the characters are wrapped inside an inline box e.g. <span>0</span> (fragmenting the text content, producing multiple renderers), the content shows up fine.

[alan]

Apparently LegacyInlineTextBox can't hold more than 65535 characters.

unsigned short m_len { 0 };

arithmetic overflow causes m_len -> 0 and the rest of the layout believes it's a blank box.

[alan]

Created attachment 453745 [details]
Patch

[EWS]

Committed r290782 (248026@main): <https://commits.webkit.org/248026@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 453745 [details].