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.)
confirming on Linux. roc, this smells like your kinda thing....
14 years ago
I borked up the case of "views which extend to the left or above their origins and have widgets" in nsViewManager::Refresh(). Patch coming...
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 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 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 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.
*** Bug 201486 has been marked as a duplicate of this bug. ***
Comment on attachment 122982 [details] [diff] [review] fix a=asa (on behalf of drivers) for checkin to 1.4.
Fix checked in.
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.
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.
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. ***
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?
BeOS port regression should open a new, BeOS-only bug. /be