Closed Bug 587418 Opened 9 years ago Closed 9 years ago

There is an invisible rectangle region that causes events within to become undetectable.


(Core :: Widget: Cocoa, defect)

Not set





(Reporter: illusionmist62442, Assigned: mstange)



(Keywords: regression)


(1 file)

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:

FYI, when I was just recording it I found out that the region can be detected by the screencast app, see this:

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.
Looks like it's bug 508906 that causes it.
Component: Layout → DOM: Events
Version: unspecified → Trunk
QA Contact: layout → events
(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:

Maybe it's bug 557986 then?
All right I'll shush now and let you guys figure that out... :P
Ever confirmed: true
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.
Assignee: nobody → mstange
Blocks: 557986
Component: DOM: Events → Widget: Cocoa
Keywords: regression
QA Contact: events → cocoa
Hardware: x86 → All
Got it.

It's caused by WarpDaemon which of course comes with 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?
Attached patch v1Splinter Review
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.
Attachment #475566 - Flags: review?(joshmoz)
Blocks: 585663
Comment on attachment 475566 [details] [diff] [review]

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.
Attachment #475566 - Flags: review?(joshmoz) → review+
Attachment #475566 - Flags: approval2.0?
Comment on attachment 475566 [details] [diff] [review]

Approved for 2.0 but please don't land until beta 8 (don't want to pile on to beta 7).
Attachment #475566 - Flags: approval2.0? → approval2.0+
Now that beta7's been branched, could someone kindly land this to trunk? This little bug just gets so annoying sometimes.

Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8
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
Target Milestone: mozilla2.0b8 → mozilla2.0b7
You need to log in before you can comment on or make changes to this bug.