[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSCursor mismatched push and pop
From: |
David Chisnall |
Subject: |
Re: NSCursor mismatched push and pop |
Date: |
Sat, 5 Oct 2013 15:37:28 +0100 |
On 5 Oct 2013, at 12:53, David Chisnall <address@hidden> wrote:
> http://theravensnest.org/NSCursor.1.log
>
> This has the event delivered with every sendEvent: message logged, and is
> showing the mouse-over-text-field-when-window-created-gets-ibeam-cursor-stuck
> bug.
This one is clearer: http://theravensnest.org/NSCursor.2.log
This shows the bug, in quite a small trace. push, pop, and set messages are
logged, with a back trace on every [NSCursor set].
When the NSCursor class is initialised, it sets an initial arrow cursor, but
does not push it onto the stack.
This is then popped in response to an appKitDefined event (subtype 1). Oddly,
this actually does set a cursor, even though there have been no -push messages
before that point and so I'd expect the array to be empty. This is inside the
NSTextView's updateState: method (which calls [NSWindow
invalidateCursorRectsForView:], which calls [NSView discardCursorRects:].
There's then another pop, from the window setting its bounds.
There's then a cursorUpdate event, which triggers a push. This is called from
[NSCursor mouseEntered:] and is the one that sets the i-beam cursor.
There's then another push from [NSCursor mouseEntered:], of the i-beam cursor
again, then again.
Then there's a pop, which restores the i-beam cursor, but is probably intended
to restore the arrow cursor.
It seems that we are pushing the i-beam cursor too many times and I think
that's because we're delivering a mouseEntered: event and then another
mouseEntered: event in sequence. I'd have expected that we'd get a
mouseExited: event first (from the old rectangle), and then a mouseEntered:
event (from the new one), so we'd pop the i-beam and then push it back again.
Looking at the NSWindow code, it appears that we should be getting the event
delivery in the right order, as long as _lastPoint actually is the last point
where we did intersection checking. It appears that it is set in response to
some mouse events that don't trigger cursor checking and also in response to a
-resetCursorRects message.
David
-- Sent from my Cray X1
- NSCursor mismatched push and pop, David Chisnall, 2013/10/03
- Re: NSCursor mismatched push and pop, Germán Arias, 2013/10/04
- Re: NSCursor mismatched push and pop, Germán Arias, 2013/10/04
- Re: NSCursor mismatched push and pop, David Chisnall, 2013/10/05
- Re: NSCursor mismatched push and pop,
David Chisnall <=
- Re: NSCursor mismatched push and pop, Germán Arias, 2013/10/06
- Re: NSCursor mismatched push and pop, David Chisnall, 2013/10/06
- Re: NSCursor mismatched push and pop, Germán Arias, 2013/10/06
- Re: NSCursor mismatched push and pop, David Chisnall, 2013/10/06
- Re: NSCursor mismatched push and pop, Fred Kiefer, 2013/10/06
- Re: NSCursor mismatched push and pop, David Chisnall, 2013/10/06
- Re: NSCursor mismatched push and pop, Germán Arias, 2013/10/07
- Re: NSCursor mismatched push and pop, Germán Arias, 2013/10/08
- Re: NSCursor mismatched push and pop, Germán Arias, 2013/10/08
- Re: NSCursor mismatched push and pop, Germán Arias, 2013/10/08