Last Comment Bug 201442 - Absolute positioned div inside fixed positioned div causes repaint problems
: Absolute positioned div inside fixed positioned div causes repaint problems
Status: RESOLVED FIXED
[fix]
: perf, regression, testcase
Product: Core
Classification: Components
Component: Layout: View Rendering (show other bugs)
: Trunk
: All All
: P2 normal with 1 vote (vote)
: ---
Assigned To: Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
: Hixie (not reading bugmail)
Mentors:
http://www.nic.fi/~tapio1/Teaching/in...
: 201486 (view as bug list)
Depends on:
Blocks: 207050
  Show dependency treegraph
 
Reported: 2003-04-09 22:32 PDT by Dean Peterson
Modified: 2003-05-25 09:53 PDT (History)
14 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Test Case (994 bytes, text/html)
2003-04-09 22:49 PDT, Dean Peterson
no flags Details
fix (4.99 KB, patch)
2003-05-11 22:56 PDT, Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
dbaron: review+
dbaron: superreview+
asa: approval1.4+
Details | Diff | Splinter Review
Relative children inside fixed parent (7.19 KB, text/html)
2003-05-14 11:10 PDT, Jonathan Stanley
no flags Details

Description Dean Peterson 2003-04-09 22:32:07 PDT
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 2003-04-09 22:49:24 PDT
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
div.)
Comment 2 Boris Zbarsky [:bz] 2003-04-09 22:58:55 PDT
confirming on Linux.  roc, this smells like your kinda thing....
Comment 3 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2003-05-11 22:50:43 PDT
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) (Exited; email my personal email if necessary) 2003-05-11 22:56:39 PDT
Created attachment 122982 [details] [diff] [review]
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) (Exited; email my personal email if necessary) 2003-05-11 22:58:59 PDT
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-7 (review requests must explain patch) 2003-05-12 08:51:33 PDT
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) (Exited; email my personal email if necessary) 2003-05-12 10:12:22 PDT
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) (Exited; email my personal email if necessary) 2003-05-12 18:14:58 PDT
*** Bug 201486 has been marked as a duplicate of this bug. ***
Comment 9 Asa Dotzler [:asa] 2003-05-12 20:42:28 PDT
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) (Exited; email my personal email if necessary) 2003-05-13 17:41:12 PDT
Fix checked in.
Comment 11 José Jeria 2003-05-14 07:42:40 PDT
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) (Exited; email my personal email if necessary) 2003-05-14 09:21:32 PDT
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 2003-05-14 11:10:11 PDT
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 José Jeria 2003-05-20 05:25:57 PDT
Should a new bug be opened for the flickering mentioned in comment 11, or is it
already one?
Comment 15 Matthias Versen [:Matti] 2003-05-21 14:15:46 PDT
*** Bug 206640 has been marked as a duplicate of this bug. ***
Comment 16 Sergei Dolgov 2003-05-25 05:19:37 PDT
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] 2003-05-25 09:53:48 PDT
BeOS port regression should open a new, BeOS-only bug.

/be

Note You need to log in before you can comment on or make changes to this bug.