Bug 18289 – extra bullet showing up due to display:block

• Status: NEW
• Component: CSS

[jasneet]

I Steps:
Go to 
https://support.live.com/eform.aspx?productKey=wllocal&ct=eformts

II Issue:
The right column with list of FAQs has one extra bullet showing up besides link "View more questions"

III Conclusion:
.faqviewmore { background-color:#EFEFEF;position:relative;display:block;padding-left:18px;left:-18px;}
display:block; is causing the issue; issue is resolved on removing it.

IV Other browsers:
IE7: ok
FF3: ok
Opera9.24: ok

V Nightly tested: 31446

[jasneet]

Created attachment 20299 [details]
screenshot

[jasneet]

Created attachment 20300 [details]
reduction

[Gavin Sherlock]

Created attachment 29958 [details]
Slightly smaller reduction

Compare Safari to Firefox and Opera.  Tested on Mac with r43110

[Ahmad Saleem]

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!

[Radar WebKit Bug Importer]

<rdar://problem/97532454>

[Ryan Reno]

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

[Ryan Reno]

(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.