Summary: | extra bullet showing up due to display:block | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | jasneet <jasneet> | ||||||||
Component: | CSS | Assignee: | Nobody <webkit-unassigned> | ||||||||
Status: | NEW --- | ||||||||||
Severity: | Normal | CC: | ahmad.saleem792, ap, arpitabahuguna, bfulgham, jasneet, rniwa, rreno, simon.fraser, webkit-bug-importer, zalan | ||||||||
Priority: | P2 | Keywords: | HasReduction, InRadar | ||||||||
Version: | 525.x (Safari 3.1) | ||||||||||
Hardware: | PC | ||||||||||
OS: | Windows XP | ||||||||||
URL: | https://support.live.com/eform.aspx?productKey=wllocal&ct=eformts | ||||||||||
Attachments: |
|
Description
jasneet
2008-04-02 14:49:41 PDT
Created attachment 20299 [details]
screenshot
Created attachment 20300 [details]
reduction
Created attachment 29958 [details] Slightly smaller reduction Compare Safari to Firefox and Opera. Tested on Mac with r43110 I am able to reproduce this bug in Safari 15.6 on macOS 12.5 based on attached "slightly smaller..." test case. All other browsers (Chrome Canary 106 and Firefox Nightly 104) does not show "bullet" against (No Bullet) line while Safari 15.6 does. Just wanted to share updated testing results. Thanks! The problem appears to be due to the RenderListMarker being a child of the <a> element's renderer as opposed to a sibling. Additionally, the <a> element is given a RenderBlock renderer in the buggy case vs a RenderInline renderer (which may itself not be a problem). I don't yet understand the mechanism for why the tree is being built the way it is but I suspect that might be where the fix can be found. Here's a simplified render tree of the repro case containing only one list element with (1) and without (2) display:block; (1): - DIV RenderBlock - UL RenderBlock - LI RenderListItem - A RenderBlock - RenderListMarker (2): - DIV RenderBlock - UL RenderBlock - LI RenderListItem - RenderListMarker - A RenderInline (In reply to Ryan Reno from comment #6) > Additionally, the <a> > element is given a RenderBlock renderer in the buggy case vs a RenderInline > renderer (which may itself not be a problem). This is simply because the default display property of anchor elements is display: inline. We're explicitly setting display: block in the buggy case so it should have a RenderBlock renderer instead of a RenderInline renderer. |