The default bug view has changed. See this FAQ.

[Windows and Linux, but NOT Mac] repainting problems on tall overflow:hidden div

RESOLVED DUPLICATE of bug 215055

Status

()

Core
Graphics
RESOLVED DUPLICATE of bug 215055
8 years ago
8 years ago

People

(Reporter: dbaron, Unassigned)

Tracking

({pp})

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

8 years ago
Jeffrey Zeldman blogged about a Firefox bug:
http://www.zeldman.com/2009/07/08/firefox-forces-red-background-flash/
http://www.zeldman.com/2009/07/09/firefox-test-page/
and posted a not-very-simplified test page at:
http://www.zeldman.com/foxy/

The bug appears to be present on Windows and Linux, but not on Mac.

Steps to reproduce:
 1. load http://www.zeldman.com/foxy/
 2. scroll down

Actual results: part way down the page, the white div and the content in it stops repainting, resulting in either orange background or garbage


On Linux, the repainting problems appear to start once the area we're trying to repaint is at least 32768 pixels from the top of the page.

It wouldn't surprise me if this were fixed if we did coordinate conditioning (i.e., reducing the coordinates that end up way off the edge of the page so that numbers stay under 2^16) on clipping regions (the way I think we might already do for rectangles to be filled), although I'm really not sure what the current state of that code is.
Flags: blocking1.9.2?
Is this not another manifestation of bug 215055? Either way, I've definitely
seen this in the system here before...
Keywords: pp
(Reporter)

Comment 2

8 years ago
Er, yes.  I sort of thought there was a bug, but I couldn't find one with a few searches...

I'd also forgotten about the widget issue, so I was sort of searching for the wrong things, though.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 215055
Flags: blocking1.9.2?
You need to log in before you can comment on or make changes to this bug.