Absolute positioned div inside fixed positioned div causes repaint problems




16 years ago
3 months ago


(Reporter: lethargo, Assigned: roc)


({perf, regression, testcase})

perf, regression, testcase

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [fix], URL)


(3 attachments)



16 years ago
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

16 years ago
Created attachment 120048 [details]
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
confirming on Linux.  roc, this smells like your kinda thing....
Assignee: position → roc+moz
Component: Layout: R & A Pos → Layout: View Rendering
Ever confirmed: true
Keywords: regression
OS: Windows 2000 → All
Hardware: PC → All
Priority: -- → P2


16 years ago
Keywords: perf, testcase
I borked up the case of "views which extend to the left or above their origins
and have widgets" in nsViewManager::Refresh(). Patch coming...
Whiteboard: [fix]
Created attachment 122982 [details] [diff] [review]

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 on attachment 122982 [details] [diff] [review]

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)
Attachment #122982 - Flags: superreview?(dbaron)
Attachment #122982 - Flags: review?(dbaron)
Comment on attachment 122982 [details] [diff] [review]

r+sr=dbaron, although it seems a little confusing that damageRect and
damageRectInPixels are in different coordinate systems.  (Maybe
widgetDamageRect would be better?)
Attachment #122982 - Flags: superreview?(dbaron)
Attachment #122982 - Flags: superreview+
Attachment #122982 - Flags: review?(dbaron)
Attachment #122982 - Flags: review+
Comment on attachment 122982 [details] [diff] [review]

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.
Attachment #122982 - Flags: approval1.4?
*** Bug 201486 has been marked as a duplicate of this bug. ***

Comment 9

16 years ago
Comment on attachment 122982 [details] [diff] [review]

a=asa (on behalf of drivers) for checkin to 1.4.
Attachment #122982 - Flags: approval1.4? → approval1.4+
Fix checked in.
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 11

16 years ago
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.
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

16 years ago
Created attachment 123306 [details]
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

16 years ago
Should a new bug be opened for the flickering mentioned in comment 11, or is it
already one?
*** Bug 206640 has been marked as a duplicate of this bug. ***

Comment 16

16 years ago
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?


16 years ago
Blocks: 207050
BeOS port regression should open a new, BeOS-only bug.

Component: Layout: View Rendering → Layout: Web Painting
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.