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

RESOLVED FIXED in mozilla2.0b7

Status

()

RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: illusionmist62442, Assigned: mstange)

Tracking

({regression})

Trunk
mozilla2.0b7
All
Mac OS X
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
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.
(Reporter)

Comment 2

8 years ago
Looks like it's bug 508906 that causes it.
(Reporter)

Updated

8 years ago
Component: Layout → DOM: Events
(Reporter)

Updated

8 years ago
Version: unspecified → Trunk
QA Contact: layout → events
(Reporter)

Comment 3

8 years ago
(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
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 4

8 years ago
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
(Reporter)

Comment 5

8 years ago
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?
(Assignee)

Comment 6

8 years ago
Created attachment 475566 [details] [diff] [review]
v1

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)
(Assignee)

Updated

8 years ago
Blocks: 585663

Comment 7

8 years ago
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.
(Assignee)

Comment 8

8 years ago
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.
Status: NEW → ASSIGNED

Updated

8 years ago
Attachment #475566 - Flags: review?(joshmoz) → review+
(Assignee)

Updated

8 years ago
Attachment #475566 - Flags: approval2.0?

Comment 9

8 years ago
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).
Attachment #475566 - Flags: approval2.0? → approval2.0+
(Reporter)

Comment 10

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

Thanks!
(Assignee)

Comment 11

8 years ago
http://hg.mozilla.org/mozilla-central/rev/0ec608086224
Status: ASSIGNED → RESOLVED
Last Resolved: 8 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.