Steps to reproduce: 1. Open a bugzilla query. For example http://bit.ly/QY9LLP 2. Place mouse pointer over the first bug number in the query result. 3. Move mouse up and down over all bug numbers. Actual results: Every now and then a row remains colored as if still being hovered. Other times a row doesn't get colored when hovered but the background under the bugnumber link does get correctly colored. There's also some other patterns, but it basically consists of the background not getting correctly repainted when going into or out of hover state. It seems to be an invalidation or painting problem because even when in the wrong state I can get hover effects just fine on other parts of the page, so we aren't losing track of hover matching. Switching tabs and back does clear up the problem. Also, it seems like the invalidation problems come in pairs. When a row fails to repaint correctly after unhovering, the row that I moved to often seems to fail to paint in hovered mode. Expected results: Backgrounds to be colored as appropriate when hovered and unhovered. I can get this to happen pretty regularly by moving around for just 10-20 seconds or so. Easier to catch when moving more slowly since otherwise it's easy to clobber by accident. I'm on OSX 10.8 with hardware acceleration enabled. This seemed to start happening after the dlbi landing, so marking as appropriate.
Which nightly are you on? This bug was fixed "a long time ago" in bug 795611.
Still happening for me on today's nightly.
I can't reproduce in linux-x64/basic or win7/d3d10 in the 10/5 nightly. (You're 100% super extra sure that you restarted after updating?)
I was surprised too. I even restarted twice. It's definitely harder for me to hit now, and I only seem to be able to get it if I hover the part of the table which contains the links.
Created attachment 668712 [details] Screenshot I'm not hovering any part of the table when this screenshot was taken. This is after triggering the bug a few times.
Matt looked at bug 795611, so hopefully he can look at this one as well. This doesn't seem critical for release, although we would take a low risk fix once found.
Assignee: nobody → matt.woodrow
tracking-firefox18: ? → -
I can't reproduce this either :(
I get this on a daily basis (usually during triage). But i can generally reproduce within a few minutes if I try. Would it be possible to write a patch to log something which would point the way?
Still happening? If so, I think Matt can walk you through some debugging. MOZ_DUMP_PAINT_LIST=1 (environment variable) and #define DEBUG_INVALIDATIONS in FrameLayerBuilder.cpp would help.
Actually, it's been a while since I saw this. And I can't reproduce right now.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.