263686 - x.org composite and CSS position:fixed - messy display updating

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Gummi]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041001 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

Have a look at http://linuxfr.org using stylesheet
linuxfr.org/css/dlfptoolbar.css (you need to register to choose to use this
CSS-based stylesheet, sorry). The problem comes from the position:fixed attribute.
Using x.org with composite, scrolling down the page, the locked toolbar is both
moved with the page and redrawn at the bottom.
I'm attaching a screenshot to this.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[Gummi]

Attachment: A screenshot

Comment 2

[Gummi]

I suppose this layout bug was dormant, and shows up because x.org with composite
has each window (widgets can be windows too) buffered separately.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Fixed-position elements get their own widget.  So yes, whatever "x.org
composite" does to screw up widget painting is likely breaking things.

Comment 4

[Christopher Blizzard (:blizzard)]

So if you turn off COMPOSITE the problem goes away?  (This is probably a
NOTMOZILLA kind of bug.)

Comment 5

[Christopher Blizzard (:blizzard)]

Is it posible for you to build a smaller test case for testing purposes?

Comment 6

[Gummi]

Attachment: A page dump

I've dumped the faulty page, with a tiny modification so as to activate the
toolbar by default.

Comment 7

[Gummi]

I've tested it and it worked with konqueror, failed with mozilla/firefox/epiphany.
It could be a xorg or xcompmgr bug, I'll file it there too.
It doesn't exactly depend on COMPOSITE in the x.org config, rather on running
xcompmgr - the composite manager, similar to a window manager.

Comment 8

[Gummi]

Just stumbled upon this, which seems a simpler test:
http://gruppy.sicem.biz/pantallazos

Comment 9

[Pete Harlow]

Attachment: Page Dump

In the attached page dump there are two documents which are identical except
one has html as an extension, the other xhtml. Both files render correctly with
Konqueror 3.1.4, Firefox 1.0 and Mozilla 1.7.3 running under Linux. However,
with Mozilla 1.8a5, the html page renders correctly, but with the xhtml page
the position:fixed block in the top rh corner breaks up on scrolling. The
a:hover hotspots remain fixed in the correct place, but the painting of the
background appears fixed to the canvas.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Pete, you're almost certainly seeing bug 268111, not this bug.

Comment 11

[Pete Harlow]

Boris, You are right in that I am seeing mostly bug 268111 symptoms, but I
missed this bug on my search or I would have probably posted there. However, the
test cases in the two bugs reassigned to bug 268111 reposition the boxes
'cleanly', in my test case bits of the box end up littered all over the scroll
range of the viewport. Is it worth reposting the test case to bug 268111? I also
added a comment to the discussion on the W3C list.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Pete, I'd suggest testing with a build that has the patch for bug 268111, and if
that does not fix the problem, reporting a new bug...

Comment 13

[Pete Harlow]

Boris, I patched 1.8a5, but exactly the same, new bug to follow...

Comment 14

[Boris Zbarsky [:bzbarsky]]

Pete, please cc me on that bug, ok?

Comment 15

[Gummi]

With the bugzilla swipe, I'm going through my unconfirmed bugs. This one is
still in existence with mozilla 1.8b. Can someone mark this confirmed, using
http://gruppy.sicem.biz/pantallazos or the testcase at bug 268111 ?
I should probably ask for the canconfirm privilege, where do I get this?

Comment 16

[Boris Zbarsky [:bzbarsky]]

Not a view rendering issue in any case...

Comment 17

[dorrin]

Could this perhaps be the same bug as bug 282109?

Comment 18

[Thomas Jollans]

I can confirm that this happens with xcompmgr, xfwm4 and compiz on x.org/nvidia (not fixed in 7.1), but NOT with compiz on Xgl on x.org/nvidia or with composite enabled but without composite manager.
It should be fixable since the problem does not occur in Konqueror.
see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=376304 for another example w/ screenshot, there on xfwm4.

Comment 19

[pholder]

Attachment: Garbled rendering after a scroll up

I confirm this problem on FF 1.5.0.7 using beryl or xfwm4 on Xorg 7.1 w/Composite extension enabled running nvidia's 8776 or 9626 drivers. See attachment for a test case from http://developer.gnome.org/doc/API/2.0/gobject/index.html

Comment 20

[Gummi]

Still here in firefox 2.0 RC3 (in edgy).

Re comment #17: These seem to be the same.

Basically, bug 282109 adds that this doesn't happen when there's an iframe somewhere in the page, and this can be tested by using auto-scrolling (in preferences, advanced, general).

Comment 21

[Boris Zbarsky [:bzbarsky]]

I'd actually be more interested in how this looks on trunk than in how it looks in Firefox 2 (where I wouldn't expect anything to have changed in this regard from Firefox 1.5).

Comment 22

[Gummi]

Using today's (20061022) trunk, there is a big improvement.
The overlay works when the page is left alone, but is somewhat jumpy while scrolling; it feels as if it was moved respective to the background to stay in the same place, but sometimes doesn't quite catch up.
Whether there's an iframe in the page is no longer relevant.

Comment 23

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Minusing; need new info with recent X and composite to be able to diagnose.

Comment 24

[Tony Houghton]

I'm still seeing the problem on all the developer.gnome.org API doc pages with FF 2.0.0.3 on xorg 7.2-3 on Debian amd64 and nvidia-glx with beryl from recent svn and been seeing it with all versions for some time. It's also been happening with compiz and also affects my laptop with Ubuntu Feisty x86 and ATI graphics (using the open xorg driver).

Here's a site that uses position:fixed but *doesn't* trigger the bug: <http://www.realh.co.uk>.

Comment 25

[Michael Wu [:mwu]]

WFM on trunk using http://developer.gnome.org/doc/API/2.0/gobject/index.html. Can someone else confirm?

Comment 26

[Pianohacker]

Confirmed on Linux with Ffx 2.0.0.3, nVidia 100.14.11 drivers, and Beryl/Xcomposite. The iframe seems to be the deciding factor, though the realh page doesn't have an iframe.

Comment 27

[Boris Zbarsky [:bzbarsky]]

Pianohacker, Michael was asking whether anyone still sees the problem on _trunk_.  2.0.0.3 is based on the 1.8 Gecko branch; since then a lot of the painting code has been rewritten.  You'd want to test with one of the Firefox 3 alphas.

(On a side noe, you really shouldn't be using 2.0.0.3 -- there have been two security releases since then....)

Comment 28

[Pianohacker]

WFM on gobject page also with trunk and same specs.

Comment 29

[Boris Zbarsky [:bzbarsky]]

Excellent!  Thank you for testing!