[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSCursor mismatched push and pop

From: Germán Arias
Subject: Re: NSCursor mismatched push and pop
Date: Sun, 06 Oct 2013 01:41:58 -0600

El sáb, 05-10-2013 a las 15:37 +0100, David Chisnall escribió:
> On 5 Oct 2013, at 12:53, David Chisnall <address@hidden> wrote:
> >
> > 
> > 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:
> 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

Well, this confirms what I supposed. When the window is displayed, this
calls the method -discardCursorRects. This will call the method
-resetCursorRects when the window process the next event (the
AppKitDefined) and will post NSCursorUpdate events. Then the menu is
added, and this cause an extra call to -discardCursorRects and more
NSCursorUpdate events. But these calls to -discardCursorRects occurs too
fast, and the corresponding NSCursorUpdate events, that are posted at
queue, are processed to late. You can see four NSCursorUpdate events
after the menu has been added. But, of course, NSWindow don't checks if
the cursor rectangles are still valids, or if these has been discarded
by a previous call to -discardCursorRects.

Thanks for this log David. Could you provide the log for the other bug?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]