I'm mildly dubious about whether this is a good idea mostly because Matplotlib already binds so many keys/buttons by default that it's a bit difficult to find "available" keys when one wants to write one's own interactive app (for example, in mplcursors, I bind moving the cursor to shift-left/right as left/right is already taken by forward/backward).
Especially, in this case, it's not even something that's togglable via rcParams["keymap.foo"].

Perhaps extend rcParams["keymap.forward/back"] to also support MouseButton.FOO? At least this way it's configurable.

Also, despite its name, I would consider putting that functionality also in key_press_handler (with a first dispatch on the event type) (possibly rename key_press_handler to event_handler with a property to handle the deprecation, yada yada) to make it easier for someone to disconnect all handlers (as I don't think many will want to disconnect the keypress but not the mousepress handler; and if they really want to have one but not the other they can always edit the rcParams entries).

Thanks for the feedback. IMHO you are addressing issues much larger than the scope of the PR.

Configurability

Configurability would be nice, but honestly, I don't see the need. Will someone really confiure other mouse buttons to forward/backward? It's also unlikely that someone wants to use the forward/backward mouse buttons for something else. The semantics is quite unambiguous and you'd have to have a really good case to do it and not surprise your users at the same time. We also don't provide custom bindings for left/right mouse buttons.

If someone has such special needs, they can (as before) do it based on the respective GUI toolkit. Deactivating the effect of the PR is as simple as disconnecting the button press handler.

Changes to the event system

Renaming key_press_handler to event_handler is not a good idea since there are many other events unrelated to keyboard and mouse input. If anything that would be an input_event_handler. However, I think most GUI toolkits handle keyboard and mouse events separately (not that it neccessarily has to be that way, but they had reasons and programmers are used to it). Any backward-incompatible change of the API would have to be thought trough thoroughly.

Also, if the main reason for a single handler is to be able to disconnect easily, we should instead add a disconnect_all() method. Having separate handlers for separate events makes it easier to reimplement them. Say, I want to do my own key press handling, I would have to reimplement the input_event_handler and redo the dispatch logic there to still keep the mouse events working.

Summary

I think, that the current PR is narrow and specific on just implementing the default forward/backward behavior within the current event logic. It doesn't make it more difficult to transition to something else later.

Deactivating the effect of the PR is as simple as disconnecting the button press handler.

But this has to be done on a canvas-by-canvas basis, unlike other keybindings that can be disabled globally through the rc system.
The situation with left/right is not really comparable as they don't do anything by default, they are only meaningful when a tool is active.
Regardless of the other changes (which I agree are a bit of a distraction), I think at least you should set

keymap.forward: right, v, MouseButton.FORWARD

(with the corresponding parsing code in rcsetup) and then have button_press_handler lookup the relevant entries in that rcParam.

Agreed on using rcParams. Wouldn't it be better to define a separate

mousemap.forward:  MouseButton.FORWARD

We could get int trouble with 'up', which is a key, but currently also the name for the wheel-up action (not that it's has a configurable action right now, but we should avoid possible future clashes).

That's why it'd "MouseButton.UP", not "up".
Having separate entries for mousemap would work too, I'm just trying to prevent the list of rcParams from growing too much, but no strong opinion there.

Anyone has opinions on rcparms

keymap.forward: right, v, MouseButton.FORWARD

vs.

keymap.forward: right, v
mousemap.forward: MouseButton.FORWARD

?

Using the keymap.forward/back for configuring also the mouse buttons.

keymap.forward: right, v, MouseButton.FORWARD

I like folding it into keymap.* configuration but am 50/50 on folding the implementation into the keypress handlers.

Lean slightly towards a separate function as that would also leave a clear place to put 'zoom-on-scroll'.

This is not in the keypress handler. button_press_handler is a separate method analogous to key_press_handler. I've chosen the name according to the event names key_press_event -> key_press_handler and thus button_press_event -> button_press_handler.

The question is: should there be one handler per event type? Or do we collect multiple events with a handler (which would then be more generic key_event_handler / mouse_event_handler)?

rebased.

What's new entry added.

Not sure if @tacaswell has any further comments.

Merging. If @tacaswell still has comments, we can still update...

This actually works out-of-the-box with GTK3 as well. The mouse buttons are just passed through directly and are already 8&9.