When a webpage has a <p> inside a list element, two breaks are rendered. The behaviour deviates from IE and Firefox, though might be conformant with standards. Repro: Use the attached file to reproduce the bug
Created attachment 15233 [details] <p> inside <li>
This is a bug (and a rather basic one at that).
As Hyatt pointed out, the problem is that the marker gets put before the <a> instead of inside the <p>, because getParentOfFirstLineBox() thinks that the <a> is going to have a line box. I tried to fix it by changing - if (currChild->isInline()) + if (currChild->isInline() && (currChild->firstChild() || !currChild->isInlineFlow())) But the firstChild() check isn't right, for example if the child contains only skipped whitespace. I don't know how to tell if the child is going to generate lines.
Created attachment 15255 [details] Check if the inline really generates line boxes This checks that the inline actually has some non-skipped content before placing the marker outside it. It makes two editing test fail: editing/pasteboard/4861080.html - I don't know what it's supposed to test once this bug is fixed editing/pasteboard/paste-4039777-fix.html - I don't understand the old results (they don't seem to be what's described or what I would expect) It might be better not to call inlineChildGeneratesLineBoxes() in all cases except when curr is an anonymous block with continuation.
Created attachment 15324 [details] Check if the inline really generates line boxes Also fixes the <ul><li><div><ul><li>foo</li></ul></div><br></li></ul> case, which was rendered completely wrong in quirks mode, making it match Firefox by not applying the quirk if the list is not a child of the list item. As far as I can tell, the affected editing test was testing buggy conditions that no longer occur with this patch, but I did not want to remove it.
Comment on attachment 15324 [details] Check if the inline really generates line boxes r=me
Landed in r24255.