555763 - Dots in front of nested UL item look like bold in child frame

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[chado]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a4pre) Gecko/20100329 (Firefox/3.7dev) Minefield/3.7a4pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a4pre) Gecko/20100329 Minefield/3.7a4pre ID:20100329040204

In some cases, especially at first load, about nested UL 
in child frame (frameset or iframe), dots in front of list item 
for second level UL look like bold.


Reproducible: Always

Steps to Reproduce:
1. open test URL.
   it can be happened here at first load, then no need following steps.
2. confirm that the right frame have scroll bar.
3.1 reload right frame.  or 
3.2 select all in right frame (ctrl + A).  or
3.3 select some lines including any list item(s) in right frame, 
    then release selection (click empty area.)

Actual Results:  
dots in front of list item for second level UL look like bold.


Expected Results:  
all dots in front of list item look not bold.


not sure but looks required to be reproduced:
1. in the child frame.  frameset or iframe.
 1.1. frames divided not in percentage (for step 3.1)
2. child frame has scrollbar.  vertical or horizontal.
3. style like "body { background: SomeColor; }" specified.
4. second level of nested UL.  not reproduced on OL.

after it happened, making that tab behind any other tab, window, 
or application, then raising back, the issue has gone.

builds not reproduced:
rv:1.9.3a2pre) Gecko/20100228 Minefield/3.7a2pre ID:20100228035348

builds reproduced:
rv:1.9.3a3pre) Gecko/20100301 Minefield/3.7a3pre ID:20100301035507
rv:1.9.3a4pre) Gecko/20100329 SeaMonkey/2.1a1pre ID:20100329010643
rv:1.9.3a4pre) Gecko/20100329 Minefield/3.7a4pre ID:20100329040204

I'm seeing this on WinXP SP3 and Linux (Ubuntu 9.10-ja on VirtualBox Guest VM)

more info:
Selecting "ul long + js" from the left frame of test URL, 
little DOM operations using JavaScript can be tested.
Switching style.display or changing border color (hovering on "none")
can cause the issue.

Comment 1

[chado]

Attachment: screenshot complex #1

showing expected and actual cases.

Comment 2

[Arie Paap [:wildmyron]]

Confirmed. I saw this on Google Reader which fits your reuirements to reproduce (not sure about "body { background: SomeColor; }" though)

Perhaps similar to Bug 406782 ?

Comment 3

[Boris Zbarsky [:bzbarsky]]

chado, what are the changeset ids (from about:buildconfig) of the Feb 28 build that doesn't show the problem and the March 1 build that does?

Comment 4

[chado]

rv:1.9.3a2pre) Gecko/20100228 Minefield/3.7a2pre ID:20100228035348 from 
http://hg.mozilla.org/mozilla-central/rev/3874a469cf09 does not show the issue.

rv:1.9.3a3pre) Gecko/20100301 Minefield/3.7a3pre ID:20100301035507 from 
http://hg.mozilla.org/mozilla-central/rev/e7970f6c7cdd does.

Comment 5

[chado]

Works for me today.  Looks resolved in somewhere from 
rv:2.0b2pre) Gecko/20100715 Minefield/4.0b2pre ID:20100715040517 to
rv:2.0b2pre) Gecko/20100716 Minefield/4.0b2pre ID:20100716040830 .

Resolving as WFM.

Comment 6

[Alice0775 White]

Fixing range pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=92339b84d089&tochange=e1d7fd5255fd