Closed Bug 300904 Opened 17 years ago Closed 12 years ago

Mouse move events fire even if the window is covered by dashboard or Dock menus

Categories

(Core :: Widget: Cocoa, defect)

All
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.9.3a1

People

(Reporter: ben.holladay, Assigned: mstange)

References

Details

Attachments

(1 file, 6 obsolete files)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b3) Gecko/20050714 Camino/0.9a2
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b3) Gecko/20050714 Camino/0.9a2

When you reveal the desktop, using by default the F11 shortcut, the components
of the web page are still affected by mouse movement.  For example if you find
any page with some hyperlinks on, press F11, and move your mouse to where the
link would have been on the screen, the mouse cursor changes, and if you can see
the bottom of the camino window you can see the URL of the page.

This also happens when you use expose's all windows, but it is easier to
demonstrate using a flash page.  All of the mouses movements still change the
flash object relative to where it would have been on the screen.

This only happens if camino was the last application to be in view (It's menu is
at the top) before you use expose's all windows or desktop expose.  I don't know
if this is a bug with os x, however I can't recreate the same problem with safari.

Reproducible: Always

Steps to Reproduce:
Desktop expose:
1. Go to any page with hyperlinks, one with lots works better such as a forum.
2. Do the desktop expose - F11 by default or hot corner
3. Mouse over where the hyperlinks were before you exposed the desktop

All windows expose
1. Go to a flash page, something like H*R's main page (
http://www.homestarrunner.com/main1.html )
2. Expose all windows - F9 by default
3. mouse over where the active flash components were, you will see/hear actions
on the small camino window.

Actual Results:  
The links and flash were still affected even though the window was not there.

Expected Results:  
Nothing
yeah, i see this. i think this is a duplicate of another bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Web page still 'on-top' when looking at desktop and exposee / expose → Web page still 'on-top' when using expose
Whiteboard: dupeme
I'm pretty sure it's a dupe, too, but I can't find the original right now.
*** Bug 322872 has been marked as a duplicate of this bug. ***
Summary: Web page still 'on-top' when using expose → Web page still 'on-top' when using expose or dashboard
For the record, I can't find anything that this is a dupe of either.

cl
Fx has problems with mouseovers, etc., firing 100% of the time when the app is in the background, but we don't have that problem.  Maybe that's what we were thinking of?  Or one of the tooltip bugs (bug 312411, bug 285601, bug 311220)?

Adding "mouseover" to the summary to perhaps make this easier to find in the future....
Summary: Web page still 'on-top' when using expose or dashboard → Web page still 'on-top' when using expose or dashboard (mouseovers fire)
Also happens with the "wait cursor".  It shows up in Dashboard when Camino's loading a page.
Heh, bug 209565 was originally reported with Camino.  Still not sure that's exactly the same bug as this, though.
I just noticed that if you have Terminal as the front-most app and you hit F11 you can hover over where Terminal _was_ and you can see the cursor change as if the window was still there.  Easily seen if you are doing a build in a Terminal window so that stuff is scrolling by.

So, unless I misunderstand this bug, this behaviour does not seem specific to Camino.  Every app I try does this.
Obviously can't be a problem with anything before 10.4...

Per comment 8, I wonder if this is simply an OS "bug" -- or rather, intended behaviour, since it seems to be by design.

cl
Assignee: mikepinkerton → nobody
OS: Mac OS X 10.2 → Mac OS X 10.4
QA Contact: general
Per further investigation, the Expose and Dashboard cases seem to be separate. I can reproduce the Dashboard portion of this bug in any Gecko browser, but not in apps that use WebKit to render the content area.

I can reproduce the initial behaviour of the Expose portion of this bug in *any* OS X app. Moving the cursor once Expose is triggered (via, say, F11) causes the hand cursor to go away as expected. I'm not sure what non-browser apps I could try to reproduce the rest of the Expose portion in.

cl
Moving to Core: Widget.
Assignee: nobody → mstange
Status: NEW → ASSIGNED
Component: General → Widget: Cocoa
Product: Camino → Core
QA Contact: general → cocoa
Hardware: PowerPC → All
Summary: Web page still 'on-top' when using expose or dashboard (mouseovers fire) → Mouse move events fire even if the window is covered by expose or dashboard
Whiteboard: dupeme
Version: unspecified → Trunk
Duplicate of this bug: 131758
Attached patch wip (obsolete) — Splinter Review
Need to see how this interacts with the tests from bug 470845.
Attached patch v1 (obsolete) — Splinter Review
Return of the tracking rects! :)

It turns out that looking at our own views' rects won't be any help in finding out whether the mouse is over a window of a different app that's in front of one of our own windows. Apparently the only thing that can answer this question is a tracking rect.
It should be noted that tracking rects still work, even though we turn off *cursor* rects. And since Compositor removed most child widgets I'm not fearing any performance hit.

In general I've found tracking rects to be very reliable. They just have one major drawback: When you create a tracking rect, it doesn't tell you whether the mouse is already over it. Instead you have to wait for the mouse to leave or enter the existing rect, and only when that has happened, you can be really sure where the mouse is.

That's the only reason for keeping our current mouse-in-view tracking system (which works with NSMouseInRect and [NSView hitTest:]).

I've added a mouseEnterState field to ChildView, which is either "unknown", "inside" or "outside". Whenever our NSView geometry changes it's reset to "unknown" and updated when the tracking rect informs us about mouseEnters and exits.
Attachment #402287 - Attachment is obsolete: true
Attachment #404182 - Flags: review?(joshmoz)
Markus, will this fix the thing I've seen recently where I'm seeing :hover effects on crash-stats "Query Results" pages even though I'm selecting something in another app's Dock menu (which just happens to be on top of the crash-stats page)?  Or is that bug 209565, or even some other bug?
This will fix it.
Comment on attachment 404182 [details] [diff] [review]
v1

+- (void)removeTrackingRect
+{
+  if ([self window] && mTrackingRect) {

Is it really necessary to check "[self window]" here? That should never be false when mTrackingRect != 0.

+  [newContentView setAutoresizingMask:(NSViewWidthSizable | NSViewHeightSizable)];

Why does this become necessary with this patch?

According to Apple docs:

"If you use tracking rectangles, you should be sure to remove and reestablish them when you change the frame rectangle of the view object that contains them. If you’re creating a custom subclass of NSView, you can override the setFrame: and setBounds: methods to do this, as shown in “Compatibility Issues.”"

I see you've done this for setFrame:, but what about setBounds:?
Attached patch v2 (obsolete) — Splinter Review
(In reply to comment #17)
> (From update of attachment 404182 [details] [diff] [review])
> +- (void)removeTrackingRect
> +{
> +  if ([self window] && mTrackingRect) {
> 
> Is it really necessary to check "[self window]" here? That should never be
> false when mTrackingRect != 0.

Good point. Removed the check.

> +  [newContentView setAutoresizingMask:(NSViewWidthSizable |
> NSViewHeightSizable)];
> 
> Why does this become necessary with this patch?

I'm actually a little surprised that it wasn't necessary before it ;-)
Without this, resizing a popup window won't call setFrame or setBounds on the content view, and [view frame] will always return a 0x0 sized rect. I don't know why drawing into them has always worked regardless.

> I see you've done this for setFrame:, but what about setBounds:?

We're not calling setBounds anyway, if I recall correctly, so I thought it was unnecessary. But I guess it doesn't hurt to add it, so I've done that in this patch.
Attachment #404182 - Attachment is obsolete: true
Attachment #405385 - Flags: review?(joshmoz)
Attachment #404182 - Flags: review?(joshmoz)
Attachment #405385 - Flags: review?(joshmoz) → review+
http://hg.mozilla.org/mozilla-central/rev/3ee95c194798
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
Attached patch v3 (obsolete) — Splinter Review
This uses the private API CGSGetScreenRectForWindow to get the rect of windows that don't belong to our process.
Attachment #405385 - Attachment is obsolete: true
Attachment #407723 - Flags: review?(joshmoz)
Attached patch v3.1 (obsolete) — Splinter Review
Remove one superfluous variable.
Attachment #407723 - Attachment is obsolete: true
Attachment #407724 - Flags: review?(joshmoz)
Attachment #407723 - Flags: review?(joshmoz)
Comment on attachment 407724 [details] [diff] [review]
v3.1

This is not ready yet.
Attachment #407724 - Flags: review?(joshmoz)
Attached patch v3.2 (obsolete) — Splinter Review
Attachment #407724 - Attachment is obsolete: true
Attachment #411399 - Flags: review?(joshmoz)
Status: REOPENED → ASSIGNED
I just discovered that these patches don't fix the "reveal desktop" case, so tweaking summary.
Summary: Mouse move events fire even if the window is covered by expose or dashboard → Mouse move events fire even if the window is covered by dashboard or Dock menus
Comment on attachment 411399 [details] [diff] [review]
v3.2

Window level 20 happens to be the Dock. You can see this by printing out the value of "kCGDockWindowLevel", which is really this call:

CGWindowLevelForKey(kCGDockWindowLevelKey)

I suggest using kCGDockWindowLevel instead of a constant so if it changes we track that, but cache the value since it is really a call.
Attachment #411399 - Flags: review?(joshmoz) → review-
Attached patch v4Splinter Review
Attachment #411399 - Attachment is obsolete: true
Attachment #416436 - Flags: review?(joshmoz)
Attachment #416436 - Flags: review?(joshmoz) → review+
Comment on attachment 416436 [details] [diff] [review]
v4

>+  extern CGSConnection _CGSDefaultConnection(void);

I'm not a fan of "(void)" signatures, please just use "()".

>+  // We're not on 10.6, so we have to fall back to private API calls.

Make this "10.6+" for accuracy, or re-word the comment to describe the actual API check we are doing.

If I remember correctly, the tracking rect solution was actually more correct than this solution in that it handles some edge-cases better (which window levels are ignored, that sort of thing). This latest version of the patch is probably faster but we'll mishandle some edge cases (likely a good trade-off for now). If this is true, can you please add a comment making it is clear why we chose this solution?
Done.

http://hg.mozilla.org/mozilla-central/rev/e69c8fde7474
Status: ASSIGNED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
Depends on: 585663
Depends on: 658500
You need to log in before you can comment on or make changes to this bug.