User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b4pre) Gecko/20100814 Minefield/4.0b4pre Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b4pre) Gecko/20100814 Minefield/4.0b4pre There seem to be an invincible box overlaid on top of the UI which block events such as hover to be detected. At first I thought it's only in the content area, but then I found that this region is TOPMOST to all UI elements. I recorded a screencast to explain it, watch the cursor: http://dl.dropbox.com/u/1025551/example_bz.html FYI, when I was just recording it I found out that the region can be detected by the screencast app, see this: http://cl.ly/3b91550a5b5385e94ea3 Reproducible: Always Steps to Reproduce: 1. Move cursor above the "region" 2. Move, resize the window around to let the "region" cover different part of UI Actual Results: Anything within the region will not know they're hovered. Clicking works and changes the state instantly (they know they're hovered when mousedown, and it's stuck again once mouseup) Expected Results: That strange region shouldn't even exist. This bug happened between 20100802-20100803, and afterwards. I'm trying the hourlies, will post back later.

Works: http://hg.mozilla.org/mozilla-central/rev/a4d86c3a3494 Fails: http://hg.mozilla.org/mozilla-central/rev/83236349154

Looks like it's bug 508906 that causes it.

(In reply to comment #2) > Looks like it's bug 508906 that causes it. Or not, I thought there was only this bug between the two changes... Full pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a4d86c3a3494&tochange=83236349154 Maybe it's bug 557986 then? All right I'll shush now and let you guys figure that out... :P

Definitely bug 557986. Thanks for catching this! We're facing the problem of imperfect platform APIs here. One of them isn't predictable enough and the other (which isn't even a public API) doesn't give us the ability to detect invisible windows. Bug 557986 made us switch from the former API to the latter, and that's why we're suddenly affected by invisible event-blocking areas. illusionmist: Can you try to find out which application is causing this? Something seems to be running in the background that doesn't really close its window but instead only makes it invisible. The Jing application (which I see you're using) is one of those, but I've already special-cased our code to ignore it, so maybe there's something else? What you could do is to go through the list in Application Monitor and close them one by one until the invisible event-blocking area is gone. Bug 585663 is another example of such a problem.

Got it. It's caused by WarpDaemon which of course comes with Warp. http://www.ksuther.com/warp/ So because of the new API we'll have to ignore apps specifically since it's not able to detect them itself. Am I understanding right?

It turns out that in this case there's another factor we can consider - the Warp window has a window alpha of zero. This patch also fixes bug 585663.

Comment on attachment 475566 [details] [diff] [review] v1 Are you 100% sure that the alpha value is of type "float" and not of type "CGFloat"? It is pretty unusual for Apple to use raw "float" and "CGFloat" is different between 32-bit and 64-bit. If you're wrong about this we might have problems on one architecture and not on the other.

Good catch, but I've tested it now and float in fact seems to be correct. If I use CGFloat in a 64 bit build it doesn't work.

Comment on attachment 475566 [details] [diff] [review] v1 Approved for 2.0 but please don't land until beta 8 (don't want to pile on to beta 7).

Now that beta7's been branched, could someone kindly land this to trunk? This little bug just gets so annoying sometimes. Thanks!

Verified on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101018 Firefox/4.0b8pre using the example in the screencast and the steps in comment #0