User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008030706 Minefield/3.0b5pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008030706 Minefield/3.0b5pre In some cases the border is not displaying correctly, see the image for details. Reproducible: Always

Interesting, I can reproduce a variant of this by going to a ftp listing and then moving the mouse over an item, but just over the top pixel of it... sometimes the bottom border doesn't draw. If I move the mouse entirely within the item then usually the entire border gets drawn. The hover effect is an outline: tbody > tr:hover { outline: 1px solid ThreeDLightShadow; -moz-outline-radius: .3em; } So I'm guessing whatever code does invalidation doesn't quite compute the same coverage area as the outline is drawn over. Still, I wouldn't block on a ftp listing quirk here, this close to 1.9, but we should fix it soon.

I guess it's the same issue for about:crashes in bug 417098

In about:crashes the right, left and bottom outline is always not visible. While in FTP listings sometimes is visible, sometimes not.

(In reply to comment #2) > Still, I wouldn't block on a ftp listing quirk here This isn't really about ftp listings but outline not working as expected.

Plus, it's a recent regression.

range http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008-02-06-04-trunk/ and http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008-02-07-04-trunk/

So, bug 359568?

Hm maybe, but we shouldn't have been hitting the composite colors path.. and the problem looks more like an invalidation/update region bug, and that code that changed is just painting code.

That's a div with tabindex=0. Outline comes from html.css: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/style/html.css&rev=3.216&mark=472,481#468

It's not bug 359568 -- I just tried a local backout of that, no change. It seems to be related to rounding (yay!); the effect changes depending on whether the tab bar is visible or not.

Here's a testcase. Looks to be an invalidation issue with outlines. First table has an outline just on hover, and you can see the painting getting cut off constrained to the table cell. The second has an outline without hover, and things look fine. Looking at that regression range, my guess would be bug 414298; I can't back that out cleanly to verify, but there were followups in bug 416073... probably just something that was missed?

bz, can you take a look? Hopefully should be an easy fix.

The change is basically described in the comments in nsTableFrame::InvalidateFrame; the rest is just changes to pass in the old overflow area. I also sprinkled some CheckInvalidateSizeChange pixie dust on the proceedings.

I guess we'll add the test when we have infrastructure for it...

Checked in.

Comment on attachment 309356 [details] [diff] [review] Fix >RCS file: /cvsroot/mozilla/layout/tables/nsTableFrame.cpp,v >+ // descriptiong of its hackishness. s/descriptiong/description/ !?

Yeah. Spelling fixed.

verified fixed using the testcase and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041217 Minefield/3.0pre ID:2008041217 --> Verified fixed

Pushed test as http://hg.mozilla.org/mozilla-central/rev/7163ec41feac Thanks for doing that, Jonathan!