[Webkit-unassigned] [Bug 204527] Nullptr crash in RenderLayoutState::pageLogicalHeight const via RenderGrid::computeIntrinsicLogicalWidths inside RenderMarquee::updateMarqueePosition

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sat Nov 23 06:43:50 PST 2019


https://bugs.webkit.org/show_bug.cgi?id=204527

--- Comment #19 from zalan <zalan at apple.com> ---
omg this is just so bad.
What happens here is that in order for RenderMarquee (which btw is not a renderer!) to position the "scrolling" content it needs to know
1. how much space there is to scroll (this is the associated renderer's content box width)
2. how wide the content is.
<body><div>foobar</div></body> -> div's content box width is the viewport width (ignore paddings margins on body/html for now) let's say: 800px
while the content width [foobar] is 50px. Now RenderMarquee has 800px-50px space to scroll the content.
Since at this point we are in post-layout phase, we should be able to answer to both questions, but 
bad_move#1: RenderMarquee calls maxPreferredLogicalWidth() to figure out the content width which is totally bogus (regressed 8 years ago at r105772). maxPreferredLogicalWidth (as the name implies) tells you how much space the content needs when no constrains applied. While this mostly works, it's incorrect nevertheless. It should instead try to figure out that _actual_ content width.
bad_move#2: RenderGrid calls into layout while computing the preferred width. While preferred width computation is conceptually very similar to layout (measure and position), it should never call into layout() as the computed preferred width value is a prerequisite to layout. While I assume RenderGrid code deals with this circular dependency in most cases, it's incorrect from correctness pov. It should instead try to call the preferred width compute functions on the grid items.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20191123/b2859d09/attachment.htm>


More information about the webkit-unassigned mailing list