[NSEvent locationInWindow] used incorrectly in Cocoa widgets

NEW
Unassigned

Status

()

Core
Widget: Cocoa
P4
normal
10 years ago
4 years ago

People

(Reporter: smichaud, Unassigned)

Tracking

Trunk
PowerPC
Mac OS X
Points:
---
Bug Flags:
wanted1.9.1 +
wanted1.9.0.x -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
[NSEvent locationInWindow] is used in several places in Cocoa widgets
to return the current location of the mouse in an NSEvent object's
window.

The problem is that an NSEvent can sometimes have a nil window
([NSEvent window] can sometimes return nil).  When this happens,
locationInWindow returns a point in screen coordinates, not in the
coordinates of any window.

Current Cocoa widgets code doesn't anticipate this possibility.

Apple's doc on [NSEvent locationInWindow] says (in part):

"With NSMouseMoved and possibly other events, the receiver can have a
nil window (that is, window returns nil). In this case,
locationInWindow returns the event location in screen coordinates."

I'm not currently aware of any practical consequences of this mistake
(I don't currently know of any particular examples where the current
code returns an incorrect value).  But it's not too difficult to
imagine one.

In my next patch I'll post a patch that changes how locationInWindow
is used in Cocoa widgets.
(Reporter)

Comment 1

10 years ago
Created attachment 312148 [details] [diff] [review]
Proposed patch

This patch deals with the possibility that an NSEvent object might
have a nil window, and also with the possibility that the NSEvent's
window (non-nil window) might be different from the one we expect.
Assignee: joshmoz → smichaud
Status: NEW → ASSIGNED
(Reporter)

Updated

10 years ago
Flags: wanted1.9.0.x?
Looks like this got missed for 1.9 and I don't see why we should take it in a security/stability release, but let's get it back on the radar for 1.9.1...
Flags: wanted1.9.1?
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x-
(Reporter)

Updated

10 years ago
Priority: -- → P2

Updated

10 years ago
Flags: wanted1.9.1? → wanted1.9.1+
Steven, is this code change still valid/needed?
(Reporter)

Comment 5

8 years ago
My patch is long out of date.  But the underlying problem still exists
-- [NSEvent locationInWindow] is still being used without checking
whether [NSEvent window] returns nil.
(Reporter)

Comment 6

4 years ago
We still call -[NSEvent locationInWindow] in several places, and still never check whether -[NSEvent window] returns NULL.  But it's hard to say whether this is causing trouble.

In one case we do prevent -[NSEvent locationInWindow] from being used for NSMouseMoved events:

https://hg.mozilla.org/mozilla-central/annotate/5d6e0d038f95/widget/cocoa/nsCocoaUtils.mm#l110

But otherwise we don't pay any explicit attention to the problem.

I'm never going to have time for this bug.  But it might be a "good first bug" or "good next bug".  And I'd be happy to review a patch for it.
Assignee: smichaud → nobody
Priority: P2 → P4
(Reporter)

Comment 7

4 years ago
For what it's worth, the text I quoted in comment #0 is still present in Apple's current documentation for -[NSEvent locationInWindow]:

https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSEvent_Class/index.html#//apple_ref/occ/instm/NSEvent/locationInWindow
(Reporter)

Updated

4 years ago
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.