Bug 88943 – Null-pointer crash when a list marker is attached to a ruby with display:block

• Status: REOPENED
• Component: Layout and Rendering

RenderRubyAsBlock did not anticipate generated content other than :before/:after being added as children.

As reported in http://crbug.com/128906

Created attachment 147214 [details]
Patch

[Abhishek Arya]

Comment on attachment 147214 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=147214&action=review

cced Roland (ruby code expert) so that he could comment.

> LayoutTests/fast/ruby/ruby-block-outside-marker-expected.txt:8
> +          RenderListMarker at (-17,10) size 7x18: bullet

This tree does not look right. Why did RenderListMarker go inside the RenderRuby.  This will cause problems down the road. It should be the immediate child of RenderListItem or be in an anonymous block just under RenderListItem. The bug is probably in RenderBlock::addChildIgnoringAnonymousColumnBlocks it didnt do the beforeChild calculation properly to put RenderListMarker before the RenderRuby.

[Roland Steiner]

This is a duplicate of 65014 - as noted there I don't have a good answer for how this is best handled. IIRC list items are "dragged" downward into the next block, which isn't a good thing in the case of ruby. 

See also 67007 for a somewhat related issue with generated content. List items could be handled in a similar way, but that strikes me as heavy-handed.

*** This bug has been marked as a duplicate of bug 65014 ***

[Abhishek Arya]

me
question on https://bugs.webkit.org/show_bug.cgi?id=65014
why is this bug hard ? i think the bug is list marker shouldn't come inside ruby at all

Roland
It's a while since i looked at it - from what i remember, list markers are put into the block that they mark - which in this case is the ruby
IIRC they don't get their own wrapping block.

me
http://code.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/LayoutTests/platform/mac/fast/doctypes/003-expected.txt&exact_package=chromium&q=renderlistmarker%20anonymous%20renderblock&type=cs&l=12
they can be wrapped in an anonymous block
and will come before the block
child
it shouldn't intrude inside the block child.

Roland
hm, perhaps I do remember wrongly
(or the code changed since I looked last)
That would be the ideal solution, yes

me
ok yeah. i don't want new folks from stopping to try fix this bug thinking it is too hard

Roland
OTOH, I wouldn't be surprised if there is an "optimization" that avoids the extra wrapping block if the content is itself a block

me
nah! i remember the buggy code in renderblock::addchildignoringcolumnblocks
basically i think we are not going up the level as required.

[Abhishek Arya]

*** Bug 65014 has been marked as a duplicate of this bug. ***

[Abhishek Arya]

We will continue to use this bug since it has all the conversation and patch involved.