537860 - Check boxes have corruption especially when scrolling and when screen redraws testcase

Status: RESOLVED WORKSFORME

(Core :: Widget: Gtk, defect)

Description

[Matt]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6) Gecko/20091215 Ubuntu/9.10 (karmic) Firefox/3.5.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6) Gecko/20091215 Ubuntu/9.10 (karmic) Firefox/3.5.6

The check boxes do not always draw correctly. The check box corruption appears consistently but randomly across any list of check boxes. The longer lists have more occurrences and are therefore easier to notice. The corruption appearance varies mostly with scrolling, disappears when "moused over", and shifts with scrolling (both keyboard and scroll wheel).

Reproducible: Always

Steps to Reproduce:
1. Go to URL
2. If check boxes next to Misc options all appear normal, scroll page down until check boxes are off the screen
3. Scroll back up until check boxes are visible.
4. If check boxes appear correct, repeat scrolling down and then up. Should not have to repeat more than a few times.
Actual Results:  
Some of the check boxes appear incorrect.

Expected Results:  
The check boxes should always look normal.

There is a similar and much more noticeable error in Gmail but I do not know if it is the same problem.

Comment 1

[Matt]

Attachment: Check box corruption image

Here is an image of the corruption I see on check boxes.

Comment 2

[Matt]

Attachment: testcase for check box corruption

The error should be much easier to see from this testcase.

Comment 3

[Matt]

Tested on a recent build and was broken:
2009-12-21-03-mozilla-central
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091221 Minefield/3.7a1pre

Found a regression range below:

works for:
2008-03-10-03-mozilla-central
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:2.0a1pre) Gecko/2008031003 Minefield/4.0a1pre

broken for:
2008-03-11-03-mozilla-central
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:2.0a1pre) Gecko/2008031103 Minefield/4.0a1pre

Comment 4

[Matt]

I believe this is the correct bonsai. I don't know what bug this points to.

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-03-10+02%3A00%3A00&maxdate=2008-03-11+04%3A00%3A00&cvsroot=%2Fcvsroot

Comment 5

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20100104 Minefield/3.7a1pre

WFM on Windows.

Comment 6

[Matt]

I thought it was a linux only bug as I have never noticed it in windows either.

Comment 7

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

Probably bug 415163.

What GTK theme are you using?

Comment 8

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

Though bug 415163 doesn't seem related to checkboxes.

Is the regression range the same using "-trunk" builds rather than "-mozilla-central" ones?  -trunk builds should definitely correspond to ranges in CVS; mozilla-central was only experimental back then.

Comment 9

[Matt]

My theme is Clearlooks. I just tested it with the new Albatross theme and it didn't make any difference. I think that is what you asked for.

I will get back to you about the trunk builds.

Comment 10

[Matt]

The regression range is not the same on trunk. Here is what I found.

Regression range on trunk:

works for:
2008-03-07-04-trunk
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008030704 Minefield/3.0b5pre

broken for:
2008-03-08-04-trunk
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008030804 Minefield/3.0b5pre

Comment 11

[Matt]

A bonsai for that range.

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-03-07+03%3A00%3A00&maxdate=2008-03-08+05%3A00%3A00&cvsroot=%2Fcvsroot

Possibly bug 402940

Comment 12

[Karl Tomlinson (:karlt)]

I think I started seeing this when I changed or upgraded the X11 graphics driver.
Matt, are you using the "radeon" driver?

It seems to happen when only parts of check boxes are drawn.  (Focusing out and in causes fully visible boxes to be drawn correctly.)  This makes me suspect an issue when reading back from the surfaces during our "slow path" drawing.

Perhaps one of these checkins caused the slow path to be used more often:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-03-07+09%3A56%3A00&maxdate=2008-03-07+10%3A00%3A00&cvsroot=%2Fcvsroot

Comment 13

[Matt]

Yes I believe so. The only way I could find the actual driver and version listed is from the two commands below. Is there a better way?

"lspci -v" returned
...
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility X1400
...
	Kernel modules: radeon

"man radeon" had a version number listed at the bottom:
xf86-video-ati 6.12.99

Comment 14

[Karl Tomlinson (:karlt)]

(In reply to comment #13)
>     Kernel modules: radeon

I'm guessing that is a good indication that X is using the radeon driver.

You can also look for the following line in /var/log/Xorg.0.log

(II) RADEON: Driver for ATI Radeon chipsets:

or as root you can run "lsof -c X | grep drivers":

X       5408 root  DEL    REG                8,7               584082 /usr/lib64/xorg/modules/drivers/radeon_drv.so

Comment 15

[Matt]

Ok thanks. Radeon it is then. However, when running "lsof -c X | grep drivers" I get multiple results, but I suspect its normal.


Xorg    1423 root  mem    REG        8,3      5540     944999 /usr/lib/xorg/modules/drivers/ati_drv.so
Xorg    1423 root  mem    REG        8,3     22564     945006 /usr/lib/xorg/modules/drivers/fbdev_drv.so
Xorg    1423 root  mem    REG        8,3    973652     945018 /usr/lib/xorg/modules/drivers/radeon_drv.so
Xorg    1423 root  mem    REG        8,3     26512     945032 /usr/lib/xorg/modules/drivers/vesa_drv.so

Comment 16

[Matt]

Can anyone nominate for a bug to block or are we supposed to wait for a developer to do so?

Comment 17

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

Anyone can nominate. However, I don't know if we'd block a release on finding a workaround for an X driver bug (if that's what this is).

Comment 18

[Matt]

Oh ok. I think I misunderstood the nomination system. Thanks for the reply.

Comment 19

[Karl Tomlinson (:karlt)]

Adding "perf" keyword because the read-back for the slow path will be happening with all drivers, affecting performance, as reported in bug 563886.

Comment 20

[Karl Tomlinson (:karlt)]

This will be mostly fixed in bug 444870.

Comment 21

[Karl Tomlinson (:karlt)]

Most cases of this were resolved in Bug 444870.  Bug 576143 will help some of the remaining few cases.  That's as much as will be reasonable to work around what is almost certainly a bug in some versions of the Xorg radeon driver.
Seems to be fixed with xf86-video-ati 6.13.1, anyway.

Comment 22

[Matt]

Glad to hear it and this does seem fixed for me now.

Mozilla/5.0 (X11; Linux i686; rv:2.0b3pre) Gecko/20100721 Minefield/4.0b3pre

Comment 23

[Karl Tomlinson (:karlt)]

(In reply to comment #21)
> Seems to be fixed with xf86-video-ati 6.13.1, anyway.

Actually, that's only with kms enabled.
(But, I'm not recommending that.  With kms enabled, render scaling seems to be causing readback and DoSing the server.)