201442 - Absolute positioned div inside fixed positioned div causes repaint problems

Status: RESOLVED FIXED

(Core :: Web Painting, defect, P2)

Description

[Dean Peterson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030408
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030408

As soon as the page loads it has border/repaint artifacts all over it from
CSS/javascript menus that haven't even been opened.  It seems to be because the
menus have absolutely positioned DIVs as children of fixed positioned DIVs.  It
doesn't sound like something a page would want to do anyway.  I'm not sure of
the standards, though, so even if my diagnosis is correct I don't know if it's
really a Mozilla bug.

The page works fine in Mozilla 1.3.  By the 20030319 nightly blocks jump around
when you resize the page but eventually settle in to the correct place.  Between
20030321 and 20030325, the artifacts appear.

Reproducible: Always

Steps to Reproduce:
1. Just go to url
2. Optionally resize window to see artifacts jump around.


Actual Results:  
Artifacts/junk on the page.

Expected Results:  
No artifacts/junk.  Nothing of menus visible until you pull the menu down.

Comment 1

[Dean Peterson]

Attachment: Test Case

Attaching attempted test case with absolute div as child of fixed div.	I would
have added borders to both DIVs, but adding a border to the outer, fixed div
made the effect go away (as did adding both a height and a width to the fixed
div.)

Comment 2

[Boris Zbarsky [:bzbarsky]]

confirming on Linux.  roc, this smells like your kinda thing....

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I borked up the case of "views which extend to the left or above their origins
and have widgets" in nsViewManager::Refresh(). Patch coming...

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

This patch adds a bunch of comments to help explain what's going on. The actual
code changes are small but significant. They only affect the case when
(viewRect.x, viewRect.y) != (0,0) which is when the view extends above or to
the left of its origin. In that case the backbuffer was being blitted to an
incorrect offset within the widget (sometimes outside the clip region).

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 122982 [details] [diff] [review]
fix

This fixes many bugs recently filed related to painting of fixed elements.

(I know dbaron isn't technically a layout peer, but I seldom get any feedback
from kmcclusk these days. Busy man)

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 122982 [details] [diff] [review]
fix

r+sr=dbaron, although it seems a little confusing that damageRect and
damageRectInPixels are in different coordinate systems.  (Maybe
widgetDamageRect would be better?)

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 122982 [details] [diff] [review]
fix

I'll change the name as dbaron suggested.

This bug horks many uses of 'position:fixed'. It's a nasty regression. The fix
is well contained and the risk is fairly low because we're only changing
behavior for the viewRect.x != 0 || viewRect.y != 0 case, which is fairly rare.

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

*** Bug 201486 has been marked as a duplicate of this bug. ***

Comment 9

[Asa Dotzler [:asa]]

Comment on attachment 122982 [details] [diff] [review]
fix

a=asa (on behalf of drivers) for checkin to 1.4.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Fix checked in.

Comment 11

[José Jeria]

Testing with build 2003051404, Windows 2000.
This is much better now (background ok), though now there is a flickering when I
resize the browser window.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Can't do much about the flicker right now. That's always been a problem. Almost
certainly won't be fixed in 1.4.

Comment 13

[Jonathan Stanley]

Attachment: Relative children inside fixed parent

Testing with build 2003051404 under Windows 2003.

The patch resolves most of the issues, but as noted previously there is the
"flicker" on window resizing.

However, there is still a rendering/repaint issue under certain circumstances.

Most obvious is selecting an option from the list box, and this will cause the
fixed element to be offset by the amount a child element is relatively placed
by, and this happens per child element.

For a fairly complex case as per the attached test case, it certainly causes
interesting artifacts.

It "resolves" itself when the <select> element looses focus.

A more subtle repaint artifact occurs when the page is freshly loaded, and the
scroll wheel is used to scroll the page.

This doesn't happen if the window is scroll using the scroll bars.

Again, this repaint artifact will resolve itself is focus is switched to
another window, and then switched back to the window in question.

So effectively, the issue is still there, it's just that in most designs,
colour choice just happens to "hide" the artifact.

Comment 14

[José Jeria]

Should a new bug be opened for the flickering mentioned in comment 11, or is it
already one?

Comment 15

[Matthias Versen [:Matti]]

*** Bug 206640 has been marked as a duplicate of this bug. ***

Comment 16

[Sergei Dolgov]

Attachment http://bugzilla.mozilla.org/attachment.cgi?id=122982&action=view
caused REGRESSION in BeOS port.
iFrames repaint/invalidation (those are implemented as children BViews) is broken.

Should we reopen this bug?

Comment 17

[Brendan Eich [:brendan]]

BeOS port regression should open a new, BeOS-only bug.

/be