11312 - Scrolling div rendering problems

Status: VERIFIED FIXED

(Core Graveyard :: GFX, defect, P3)

Description

[Patrick C. Beard]

The following simple <div> exhibits several rendering problems:

<div style="overflow: auto; height: 100px; border: 1px solid black">
The rain in spain is mainly on the plane.<br>
The rain in spain is mainly on the plane.<br>
The rain in spain is mainly on the plane.<br>
The rain in spain is mainly on the plane.<br>
The rain in spain is mainly on the plane.<br>
The rain in spain is mainly on the plane.<br>
The rain in spain is mainly on the plane.<br>
The rain in spain is mainly on the plane.<br>
The rain in spain is mainly on the plane.<br>
The rain in spain is mainly on the plane.<br>
The rain in spain is mainly on the plane.<br>
The rain in spain is mainly on the plane.<br>
The rain in spain is mainly on the plane.<br>
The rain in spain is mainly on the plane.<br>
The rain in spain is mainly on the plane.<br>
The rain in spain is mainly on the plane.<br>
The rain in spain is mainly on the plane.<br>
The rain in spain is mainly on the plane.<br>
The rain in spain is mainly on the plane.<br>
</div>

Problem #1:  1 pixel border is incomplete along bottom edge. I suspect this this
is a clipping problem.

Problem #2:  Scrolling with the thumb scrolls most of the div, except a narrow
band along the lower edge, another clipping problem. The width of this band
varies as the position of the div itself in the enclosing scrolling view.

Problem #3:  Scrolling with the down arrow scrolls even less of the text, perhaps
yet another clipping problem.

This code works correctly on the other platforms (Win32 and Linux). The problem
is probably a serious incompatibility with the way that Mac widgets maintain
their coordinates. I think we need a serious look at how widget coordinates are
maintained on the Mac.

Comment 1

[Kevin McCluskey (gone)]

This also causes problems for gfx listboxes. Gfx listboxes are derived the from
scroll frame used for scrolling DIVS.

Comment 2

[Patrick C. Beard]

I've got this one figured out, but I'm trying to create the right fix. ETA, some
time later today.

Comment 3

[Patrick C. Beard]

Fixed in mozilla/widget/src/mac/nsWindow.cpp,1.121. nsWindow::Invalidate() wasn't
treating widgets with bounds.(x, y) <> (0, 0) correctly.
nsWindow::GetNativeData(NS_NATIVE_OFFSETX) starts with bounds.x before calling
LocalToWindowCoordinate(), so nsWindow::Invalidate() needs to call
MoveBy(bounds.x, bounds.y) on the passed-in rectangle, before calling
LocalToWindowCoordinate().

Comment 4

[Chris Petersen]

With the 8/27 Mac build (1999082712), the problem looks like it has been fixed.