If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED WORKSFORME

Status

()

Core
Graphics
RESOLVED WORKSFORME
8 years ago
7 years ago

People

(Reporter: chado, Unassigned)

Tracking

({regression})

Trunk
x86
All
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
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.
(Reporter)

Updated

8 years ago
Keywords: regression
Version: unspecified → Trunk
(Reporter)

Comment 1

8 years ago
Created attachment 435657 [details]
screenshot complex #1

showing expected and actual cases.
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 ?
Status: UNCONFIRMED → NEW
Component: General → Graphics
Ever confirmed: true
QA Contact: general → thebes
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?
(Reporter)

Comment 4

8 years ago
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.
(Reporter)

Comment 5

7 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME

Comment 6

7 years ago
Fixing range pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=92339b84d089&tochange=e1d7fd5255fd
You need to log in before you can comment on or make changes to this bug.