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

Sat Nov 23 11:48:18 PST 2019

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

--- Comment #20 from zalan <zalan at apple.com> ---
^^ too dense

What happens here is that in order for RenderMarquee (which btw is not a renderer!) to position the "scrolling" content it needs to know 2 things:

1. how much space there is to scroll (this is the associated renderer's content box width)
2. how wide the content is.

simple example:
<body><div>foobar</div></body> 
1. <div>'s content box width is the viewport width (minus paddings margins on body/html etc) let's say 800px
2. the _content_ width [foobar] is, let's say 50px. 
-> RenderMarquee has (800-50)px space to scroll the content.

Since at this point we are in post-layout phase, we should be able to answer to both questions (the content and the _content_box_ width), but

bad_move#1: RenderMarquee calls maxPreferredLogicalWidth() to compute the content width (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 what _actual_ content width is.

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/c38fc56e/attachment-0001.htm>