Summary

Fixes #29687.

When multiple TextBox widgets are used with toolmanager active (reproduced on QtAgg and TkAgg), rapidly clicking from one TextBox to another intermittently raises:

ValueError: already locked

Root Cause Analysis

button_press_event handlers are dispatched to all connected widgets in widget-creation order, not in click order. Consider two TextBox widgets, TB1 (created first) and TB2 (created second, currently active/typing):

1. User clicks on TB1 while TB2 holds the keypresslock.
2. TB1._click fires first (creation order) → calls begin_typing() → attempts to acquire keypresslock → crash, because TB2 still holds it.
3. TB2._click fires second → would have called stop_typing() and released the lock, but it is already too late.

The instrumented trace from the issue reporter confirms this ordering:

TB2 BEGIN TYPING   ← (previous session, TB2 acquired focus)
TB1 BEGIN TYPING   ← TB1's _click fires first → ValueError: already locked
TB2 STOP TYPING    ← TB2's _click fires too late

Fix

Two targeted changes to lib/matplotlib/widgets.py:

1. LockDraw.owner property (new)

@property
def owner(self):
    """Return the current owner of the lock, or None if unlocked."""
    return self._owner

Exposes the current lock holder through a clean public API, avoiding the need for callers to reach into private _owner state.

2. TextBox.begin_typing() — graceful lock transfer

lock = toolmanager.keypresslock
if lock.locked() and not lock.isowner(self):
    if hasattr(lock.owner, 'stop_typing'):
        lock.owner.stop_typing()
toolmanager.keypresslock(self)
stack.callback(toolmanager.keypresslock.release, self)

Before acquiring the keypresslock, begin_typing() now checks whether another widget currently holds the lock. If so, it calls stop_typing() on that widget directly — releasing the lock and resetting the previous owner's typing state cleanly. When the previous owner's _click handler eventually fires stop_typing(), it becomes a no-op because capturekeystrokes is already False.

This implements the "force-grab focus" mechanism suggested by @anntzer in the issue discussion.

Test

Added test_TextBox_keypresslock_race_condition in test_widgets.py that directly reproduces the race scenario:

• TB2 acquires the lock via begin_typing().
• TB1 calls begin_typing() without TB2 having called stop_typing() first (simulating the event-order race).
• Asserts that the lock transfers cleanly to TB1.
• Asserts that TB2's subsequent stop_typing() is a no-op (does not raise, does not affect TB1's lock).
• Asserts full cleanup after TB1.stop_typing().

Checklist

• Regression test added
• All existing TextBox tests pass (test_TextBox[none], test_TextBox[toolbar2], test_TextBox[toolmanager])
• No changes to public API except the additive LockDraw.owner property