Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

If mouse enters a view that does not override mouseEntered, then the superview gets superfluous mouseEntered call #200

Closed
saikat opened this Issue · 18 comments

8 participants

@saikat

If I have view A with subview B, if subview B does not override mouseEntered or mouseExited, moving the mouse on to subview B (from a point that is already on view A) will call mouseEntered on view A since the default implementation of mouseEntered just goes down the responder chain. I don't know how Cocoa handles this case.

@boucher
Collaborator
@saikat

My proposed fix link is broken, but the proposed fix was to just get rid of the nextResponder propagation in CPResponder for mouseEntered and mouseExited. Discussed here - http://groups.google.com/group/objectivej-dev/browse_thread/thread/b37e35412c4104/b09f7db0347698cf?lnk=gst&q=mouseEntered#b09f7db0347698cf . This would follow the Cocoa implementation but not docs (which I think is more intuitive).

@aparajita
Owner

Not fixed, and Cocoa does not have this behavior, but mainly because it uses NSTrackingArea. We really need to implement that to handle this correctly, because by definition the responder chain requires that events are passed up the chain. In Cocoa it no longer sends mouseEntered/mouseExited/mouseMoved to views, only to tracking areas.

@aparajita
Owner

Related to #636.

@cappbot
Collaborator

Milestone: 1.0. Labels: #accepted, #needs-patch, AppKit, bug. What's next? This issue needs a volunteer to write and submit code to address it.

@klaaspieter

From Ross in the other thread:

I think I understand what you're talking about more now. The Cocoa documentation seems to say it should work the way it does in Cappuccino, but the Cocoa implementation does not work that way.

We have been looking at the documentation of NSResponder. It states that the default implementation is to pass it to the next responder. It could very well be that mouseDown:is overridden in NSView to prevent this behavior.

@aparajita Yes, the ideal solution is to implement tracking areas (is there an issue for this?), but considering it's, in my opinion, weird behavior and not the way it works in Cocoa we should also fix this issue.

The biggest problem I see with fixing this issue is all the old code relying on it's behavior. If we fix this the resulting bugs are very hard to debug and resolve.

@aparajita
Owner
@kuon

If your app depends on this behaviour, it sounds clearly like a bug to me. Perhaps we can issue a debug warning, like "mouseEntered was not called on superview". But the issue should be fixed.

@aparajita
Owner
@klaaspieter

I have a bunch of that filtering out code as well. I also never ran into the opposite case. Let's fix this :)

@cacaodev cacaodev referenced this issue from a commit in cacaodev/cappuccino
@cacaodev cacaodev CPValue binding with test; workaround for issue #200 b27a0c0
@cacaodev
Collaborator

Since this issue was opened it seems there have been changes that affect mouseEntered. I think we should fix all at once and make some decisions !

7aa7d61 (hover states in CPControl) sets _acceptsMouseMovedEvents default value to YES in CPWindow.

1/ Is that what we want or we should set it on a class basis (YES for table view header, split view ...) ?

2/ As proposed, we can remove the nextResponder propagation in CPResponder but due to 7aa7d61 there will still be a call for CPControl subclasses for the hover state management. To avoid that, we could set a flag in CPControl if the receiver has an attribute for CPThemeStateHover and decide to turn on _acceptsMouseMovedEvents and send a mouse|Entered|Exited: based on this flag. I guess the flag computation should happen early, when we load theme attributes, and also in setValueForThemeAttribute:inState:CPThemeStateHover.

3/ For _acceptsMouseMovedEvents, we could even remove/add event listener in the DOM ? It would be cleaner.

@ahankinson

Any new updates on this issue?

@aparajita
Owner

It is still an issue until we have tracking rectangles. cacaodev has some good suggestions. At the moment this one is not a priority.

@aparajita
Owner

Related to #1783

@aparajita
Owner

I'm closing this in favor of #1783

#wont-fix

@cappbot
Collaborator

Milestone: 1.0. Labels: #wont-fix, AppKit, bug. What's next? A reviewer or core team member has decided against acting upon this issue.

@cappbot cappbot closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.