There is a bug in how moving the mouse over the plot detects what artist should be used to collect additional info about the cursor position from (in my case several Images in the axes). For a plot with multiple images this means that only one image is properly reporting z coordinates and all other images won't be able to show z coordinate info.

Example:

import matplotlib.pyplot as plt
import numpy as np
fig, ax = plt.subplots()
ax.imshow(np.random.randn(25).reshape(5, 5), extent=[0, 3, 0, 1])
ax.imshow(np.random.randn(25).reshape(5, 5), extent=[0, 3, 2, 3])
ax.set_ylim(0, 3)
plt.show()

Only moving through one of the images shows correct z coordinates in the interactive window info bar at the bottom.

The reason for this bug is an oversight in #3989:

Since Artist.contains() returns a tuple it is not usable like this:

    if my_artist.contains():
        ...

So, what is happening is that all artists are included in the list of artists that contain the event and then the wrong artist is queried for data on the location of the event.

Since the name of the method "contains" might easily in the future be prone to such bugs again, I think a better solution would be to change the return from a 2-tuple (which will always evaluate to True) to only False (not contained) or a dictionary (contained) that in minimal fashion is set up like {'artist': self} so that it evaluates to True. But obviously that would drastically change a public API, so I'm assuming this won't be an option, likely..

Sorry, I'm not sure how to best test this, I think to add a test would mean to first refactor NavigationToolbar2.mouse_move() so that getting the cursor info from all artists is in a separate helper method..

PR Checklist

• Has Pytest style unit tests
• Code is PEP 8 compliant
• no new features New features are documented, with examples if plot related
• no new docs Documentation is sphinx and numpydoc compliant
• no new feature Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
• no API change Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way