Layout info reported to scripts gets corrupted when scroll height above 17895690
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
People
(Reporter: marijnh, Unassigned)
References
(Depends on 1 open bug)
Details
Attachments
(1 file)
|
437 bytes,
text/html
|
Details |
When creating a scrollable element with content that is, say, 20 million or more pixels high, the element's scrollHeight will not grow beyond 17895690 (0x111110a). The same happens for main body scrolling.
Children scrolled fully or partially out of view in such a container, when queried with getBoundingClientRect, report negative heights and odd top/bottom positions.
(As far as I can see, the actual displayed content is laid out correctly.)
Though typical dense DOM content of that size might possibly overload the browser anyway, the use case where I'm running into this is a code editor that handles displaying large documents by only rendering the part that's scrolled into view, so the scroll height is generated by inserting large empty elements.
Attached document demonstrates the problem by creating a scrollable element with 20 million-high children.
|
Reporter | |
Comment 1•3 years ago
|
||
Not sure what happened to the attachment. Trying again to add it.
|
||
Comment 2•3 years ago
|
||
I think this is just hitting nscoord limits. Max coord is 0x3fffffff. 0x111110a * 60 is 0x3ffffe58, which is incredibly close to it. (423 app units, which is just 7.05 CSS pixels (maybe scrollbar height or such?)
|
||
Comment 3•3 years ago
|
||
Yes, nscoord becomes 1073741343 inside Element::ScrollHeight which is 0x3ffffe1f. It seems there is a relevant bug:
Description
•