The default bug view has changed. See this FAQ.

steps in text lines of a float when placed over an area with overflow:auto

RESOLVED WORKSFORME

Status

()

Core
Layout: View Rendering
RESOLVED WORKSFORME
12 years ago
9 years ago

People

(Reporter: Ingo Chao, Assigned: roc)

Tracking

({testcase})

Trunk
testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050617 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050617 Firefox/1.0+

A float is placed via negative margin above an area of a box which has
overflow:auto assigned.
The text lines show a "step" when they hit the overflowed box.
The problem is reproducible no matter if the box is currently overflown, showing
a vertical scrollbar or not. 
On a Mac build, increasing the text size +1 was needed to reproduce the problem.
[Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050619]
The testcase uses different fractional offsets for the boxes to make the problem
more reproducible.
Screenshots are attached in the testcase.

Thanks.

Reproducible: Always

Steps to Reproduce:
1. increase text size +1 or -1

Comment 1

12 years ago
I'm seeing this too with build id 2005061903
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050619

The above nightly build renders the test URL better than Firefox
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
so I guess this isn't a regression.

Opera and Konqueror render the test case correctly.

Comment 2

12 years ago
Created attachment 186879 [details]
minimal testcase

Minimal testcase where I can reproduce the problem on OS X. One might need to
zoom in to see the problem.

Comment 3

12 years ago
Created attachment 186881 [details]
Screenshot from minimal textcase

Screenshot on OS X. I zoomed in (120%) to see the problem. Depending on users
settings (font-size, resolution), this might not be needed.

Comment 4

12 years ago
Reproduced on OS X with
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050620
Firefox/1.0+ (PowerBook)
and the official Firefox 1.04.

The problem only happens with block level elements that are taken out of the
flow (float or positioning) and overlap (or are covered by) another block
element. Stacking order is not important.
On OS X at least, the overflow property must be set to 'auto' or 'scroll'.
Overflow:hidden or overflow:visible (the default) doesn't cause this problem.

I cannot reproduce the problem with Camino [2005062008 (v0.9a1)]

Comment 5

12 years ago
Created attachment 186895 [details]
more minimal testcase

with linux trunk build 2005062002, for some level of text zoom, the black text
is 1 pixel too high within the blue div.

Comment 6

12 years ago
marking NEW
Blocks: 134942
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
Assignee: nobody → roc
Component: Layout → Layout: View Rendering
QA Contact: layout → ian

Updated

11 years ago
Blocks: 305497

Comment 7

9 years ago
Ingo, if you're still reading, are you able to reproduce this bug in Firefox 3?

I can only see some kind of flickering while the elements are redrawn, but the final rendering is fine for me. Even using the different zoom methods.

The testcases work for me as well.

Comment 8

9 years ago
On OS X 10.5, all test cases work just fine, without any flickering.
On Linux / Ubuntu 8.04, I did notice some flickering with page zoom. That might be worth its own bug if none exist (I think I've seen it with other pages).
(Reporter)

Comment 9

9 years ago
Works fine for me now. Thanks.

Comment 10

9 years ago
All right, thanks for your feedback. -> WFM
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.