Bug summary

set_navigate(False) on a twinx() axes, and set_forward_navigation_events(False) on its partner, are both ignored: the toolbar adds twinned siblings to the navigation set unconditionally, so a zoom rectangle moves both y scales.

Code for reproduction

import matplotlib.pyplot as plt
import numpy as np

t = np.linspace(0.0, 10.0, 600)
y = np.linspace(0.0, 1.0, 200)
z = np.exp(-(y[:, None] - 0.5 - 0.3 * np.sin(t)) ** 2 / (2 * 0.04 ** 2))   # any image will do

fig, ax = plt.subplots()
ax2 = ax.twinx()
ax2.imshow(z, extent=[t[0], t[-1], 0.0, 1.0], aspect="auto")   # its own y, on [0, 1]
ax2.patch.set_visible(False)                                  # the standard overlay recipe
ax.set_zorder(ax2.get_zorder() + 1)
ax.patch.set_visible(False)
ax.plot(t, np.exp(-t / 6.0) - np.exp(-t), color="C0")   # a pulse for the second image

ax2.set_navigate(False)             # both opt-outs, as explicitly as the API allows
ax.set_forward_navigation_events(False)
plt.show()

Actual outcome

With the zoom tool selected, drag a rectangle over the middle of the axes. Both images zoom.

Expected outcome

Only the image with the focus should be navigated, not the twin.

Additional information

In NavigationToolbar2._start_event_axes_interaction (lib/matplotlib/backend_bases.py) the
siblings are appended before the capture test and without consulting get_navigate():

axes_to_trigger.append(ax)
# NOTE: shared axes are automatically triggered, but twin-axes not!
axes_to_trigger.extend(ax._twinned_axes.get_siblings(ax))

if _capture_events(ax):
    break

So neither opt-out applies. This looks like the remaining gap in the feature added for #1502
("twin axis panning / zooming should be toggleable", closed as fixed by #27148 for 3.9.0):
the toggle exists and works between overlapping axes, but not for a twin.

A conservative fix would filter the siblings through the same predicate already applied to the
axes themselves, so a twin that declines navigation is simply not added and existing behaviour
is unchanged for everyone else.

The visible symptom, in an overlay where the back axes holds a fixed image and the front axes a curve, is that dragging a rectangle over the shared position stretches the image vertically while the curve's y stays put. In the live instance, y zooming on the front image was disabled, and that happened correctly, but the fixed background image continued to zoom the y axis in an undesirable way.

On existing reports: #1502 ("twin axis panning / zooming should be toggleable") is the feature request this belongs to and is closed as fixed by #27148 for 3.9.0; I am not reopening it because its request has been met; the toggle exists, and what fails is that it does not reach twins. #9616 ("second y-axis does not scale correctly when using the zoom tool") was closed pointing at secondary_yaxis, so I expect the same suggestion here, and it is worth saying in advance why it does not fit: secondary_yaxis derives the second scale from the first by a pair of functions, so it suits a conversion (Fahrenheit/Celsius) but cannot host an independent overlay—in my case the back axes holds data in different units, but neither should be scaled on the yaxis.

Disclosure: the first draft of this report, and the reproduction above, were written by an AI agent working in Open Math OS from my observations; I have run the reproduction myself, understood the issues, and edited as appropriate.

The full application for context is here: https://github.com/dpthurst/core-entropy-app
(The standalone app, not the web version using Plotly.)

Operating system

Debian

Matplotlib Version

3.10.1+dfsg1

Matplotlib Backend

qtagg

Python version

Python 3.13.5

Jupyter version

N/A

Installation

Linux package manager