359649 - [xul trees] Top line in about:config blanks when mouse pointer passes over header row

Status: VERIFIED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Kyle Rhorer]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20061105 Minefield/3.0a1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20061105 Minefield/3.0a1

When viewing about:config, the top row of prefs goes blank when the mouse pointer (aka cursor) crosses the header row immediately above it.

Reproducible: Always

Steps to Reproduce:
1.  Go to about:config
2.  Pass the pointer over the header row
3.  Watch the row immediately below the header row go blank

Actual Results:  
Row blanks out

Expected Results:  
There should be no visible change

Scrolling the page refreshes the row.

Comment 1

[Hiro]

Confirm.

Mac OS X 10.3.9
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20061103 Minefield/3.0a1

Comment 2

[philippe (part-time)]

This also happens in the Bookmark Manager and in the DomInspector
In the Bookmark Manager, click on line for an entry, the next on disappears.

Comment 3

[philippe (part-time)]

Regression range
Fails
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20061101 Minefield/3.0a1 ID:2006110104

OK
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20061031 Minefield/3.0a1 ID:2006103104

Comment 4

[:Gavin Sharp [email: [e-mail]]]

Is this Mac only?

Comment 5

[-fullmetaljacket-]

wfm

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a1) Gecko/20061108 Minefield/3.0a1 ID:2006110819 [cairo]

Comment 6

[philippe (part-time)]

(In reply to comment #4)
> Is this Mac only?

Based on comment #4 and feedback in the forums: yes Mac only.
Looks like it affects all XUL trees.
From that Bonsai query: bug 358398 ?

Comment 7

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #6)
> Based on comment #4 and feedback in the forums: yes Mac only.
> Looks like it affects all XUL trees.
> From that Bonsai query: bug 358398 ?

Maybe, but that patch isn't Mac-specific; I guess it could have triggered a Mac-only widget bug, or something.

Comment 8

[:Gavin Sharp [email: [e-mail]]]

*** Bug 360182 has been marked as a duplicate of this bug. ***

Comment 9

[(not reading, please use [e-mail] instead)]

this is affecting the history sidebar on the trunk, as well.  

Comment 10

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

This is probably the worst cocoa-related bug for 1.9a1; we definitely need to fix this before 1.9a1.  sspitzer says this is a recent regression -- he did not see this when Cocoa was turned on initially.

Comment 11

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Yeah, we didn't use to see this in Camino, but I saw it in my trunk build when I went to about:config tonight.

Comment 12

[Phil Ringnalda (:philor)]

Caused or exposed, bug 358398 indeed - I backed it out to check, then forgot, and thought someone had accidently fixed this.

Comment 13

[Josh Aas]

I can also confirm that bug 358398 caused this. I double checked by backing that out with a cairo-cocoa tree.

Comment 14

[Josh Aas]

Trunk carbon Firefox does not display this bug even with the patch from bug 358398 still applied.

Comment 15

[Josh Aas]

I noticed by logging invalidation rects that it is mousing over the column title bar that causes the bug (and it is the rect for the column title bar that is being invalidated). If you move to the top row of the xul tree without ever mousing over the column title bar you won't see the top row go white.

Comment 16

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

Attachment: use Intersect, not Replace for clipping

nsClipCombine_kReplace is almost never the right thing to do; I've been tempted to change the #define to be nsClipCombine_kReplace_I_KNOW_WHAT_IM_DOING until we kill nsIRenderingContext.

The problem here is that the dirty rect that was being passed in is not an exact multiple of row height.  The display list manager takes care to set the clip to the dirty rect before calling in to the display list items.  The SetClipRect sets the clip to the entire area taken up by the table, but it did so by replacing the previous clip, thus allowing it to scribble over the entire table area.

So something was painting the entire row background without clipping to the dirty rect (which only included a few pixels from the top of the row), and then later the cell contents weren't being painted because it was actually taking into account the dirty rect.  There's an underlying bug here though, and I think it's that the native theme code wasn't using the passed-in aClipRect parameter at all, which is where the background issue comes in... but it's not, because native theme rendering isn't being used here that I can see, and fixing that didn't fix this bug (without the associated clip fix).

Comment 17

[Josh Aas]

vlad - why did this only show up in cocoa widgets?

Comment 18

[Neil Deakin]

Comment on attachment 246738 [details] [diff] [review]
use Intersect, not Replace for clipping

This is ok

Comment 19

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

(In reply to comment #17)
> vlad - why did this only show up in cocoa widgets?

Because there's still an underlying bug of something ignoring the dirty rect, perhaps because it's thinking that the dirty rect is already set as the clip.  I thought it was the native theme code, but that's not getting used here as far as I can tell.

Comment 20

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

Checked in; we should figure out what the underlying bug is, though, because it could be causing other problems.

Comment 21

[(not reading, please use [e-mail] instead)]

verified with my own build:  Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a1) Gecko/20061129 Minefield/3.0a1

vlad / josh:  is there a bug logged on the underlying issue?

Comment 22

[philippe (part-time)]

(In reply to comment #20)
> Checked in; we should figure out what the underlying bug is, though, because it
> could be causing other problems.

Would that underlying bug be the reason for bug 362189 ?