PanTool does not restore window mouse owner after panning

[mdsmarte]

Problem Description

The PanTool sets the window mouse owner to be itself when panning starts (_start_pan):

chaco/chaco/tools/pan_tool.py

Lines 257 to 259 in 192675d

	if capture_mouse:
	event.window.set_pointer(self.drag_pointer)
	event.window.set_mouse_owner(self, event.net_transform())

When panning stops (_end_pan), it sets the window mouse owner to None:

chaco/chaco/tools/pan_tool.py

Lines 269 to 270 in 192675d

	if event.window.mouse_owner == self:
	event.window.set_mouse_owner(None)

Expected behavior:

I would have expected _end_pan to revert the mouse owner back to the original owner before panning started, rather than changing it to None.

[corranwebster]

I think this is the correct behaviour: there should only be one mouse owner (ie. a component that gets all mouse events) at a time. In particular, if there is already a mouse owner, there is no way for the PanTool to get the mouse event to start the panning operation, so the mouse owner will always be None initially.

[mdsmarte]

In particular, if there is already a mouse owner, there is no way for the PanTool to get the mouse event to start the panning operation, so the mouse owner will always be None initially.

Unfortunately after 2 years I've lost the context that spawned this issue but I'm pretty sure this assumption is not always true. At any rate, here was the workaround we had to put into a custom tool that inherits from PanTool:

    def _start_pan(self, event, capture_mouse=True):
        # Workaround for chaco bug
        # https://github.com/enthought/chaco/issues/519
        self._former_mouse_owner = event.window.mouse_owner
        super()._start_pan(event, capture_mouse)

    def _end_pan(self, event):
        # Workaround for chaco bug
        # https://github.com/enthought/chaco/issues/519
        super()._end_pan(event)
        event.window.set_mouse_owner(self._former_mouse_owner)
        self._former_mouse_owner = None

I doubt this would have worked if event.window.mouse_owner were always None when _start_pan is invoked.

[corranwebster]

So I did a bit of reading through the Enable event code, and it looks like this might be able to happen if somehow the current mouse owner dispatches mouse events to other interactors somehow. The only ways that I can see that happening are:

• there is a BroadcasterTool which explicitly does this sort of thing, but also tracks mouse ownership as part of its logic (and which I don't think I've ever used) - looks like the example of its use is for multi-axis plots
• a Container (or similar, like a canvas or viewport) subclass somehow gets ownership and doesn't handle all mouse events while it is the owner and dispatches events to its children, one of which happens to be a pan tool.

In both those cases, it would seem like the error is not within the pan tool, rather it is in the owning object (or possibly in Enable for not being strict enough).

I guess I'm curious to know if you were using the BroadcasterTool since this could be pointing to an error in that code.

[mdsmarte]

I took a look and no BroadcasterTool is being used... the plot has multiple tools (including the custom subclass of PanTool), but they are all attached directly to the plot.

[corranwebster]

Had an offline conversation and had a quick look at the code in question. Seeing what else is there I am now suspicious of the BetterSelectingZoomTool - it is both a Tool and an Overlay, which means that it can potentially dispatch events it doesn’t handle up through its containing Component.

So I think the model for the error you were seeing was something like:

• BetterSelectingTool gets mouse ownership somehow
• there is a mouse interaction which it doesn’t handle, so it passes it up to the Plot
• the Plot sees if any tool will handle the event
• the PanTool handles the event and tries to get mouse ownership

The end result is that the BetterSelectingZoomTool gets into a confused state after the PanTool is done. Not 100% sure of this, but it seems plausible based on the various interactions.