@anntzer I don't think this collides with #16931 (which will fix the same bug by not doing the processing in __init__ anymore). I think it is worth merging and backporting this fix.

Thanks for this @Stefan-Mitic ! It looks like there are a couple of un-related commits on this branch. Could you please remove them? See https://matplotlib.org/devel/gitwash/development_workflow.html?highlight=rebase#rewriting-commit-history for instructions. Remember that when you push the re-written branch to github to not do what it suggests about merging and instead use push --force-with-lease.

I can handle the rebase, sure.

@anntzer I don't think this collides with #16931 (which will fix the same bug by not doing the processing in __init__ anymore). I think it is worth merging and backporting this fix.

Thanks for this @Stefan-Mitic ! It looks like there are a couple of un-related commits on this branch. Could you please remove them? See https://matplotlib.org/devel/gitwash/development_workflow.html?highlight=rebase#rewriting-commit-history for instructions. Remember that when you push the re-written branch to github to not do what it suggests about merging and instead use push --force-with-lease.

Thanks for the help @tacaswell

So if I read #15139 correctly, the same thing should be done for KeyEvent?

Yes @QuLogic, I added it to KeyEvent. Both KeyEvent and MouseEvent are LocationEvents, I think it is fine to pass those through the callback function.

Can you add tests? I think it should work in lib/matplotlib/tests/test_backend_bases.py.

@QuLogic, I'm not sure how to trigger a keypress event to invoke my callback function.
This is the code I'm trying to work with:

def test_key_event_init():
    fig, ax = plt.subplots()
    canvas = FigureCanvasBase(fig)

    def on_key_press(event):
        assert event.key == "test_key"

    canvas.mpl_connect('key_press_event', on_key_press)
    # TODO: trigger key_press_event here

Given this explanation, I'm not 100% sure that this change is the correct solution. init calling other methods that rely on a fully set-up object can be problematic (as this issue illustrates).

I don't disagree, but we have the event system we have. With super() you tend to end up is cases where either you have to do your work in the subclass first and then push it up the chain or push it up the chain and then extend it on the way out. Conceptually either works ("sub classes can affect the parent code by setting state" vs "subclasses can strictly extend the base functionality") but woe unto those who end up in code bases that do some of one and some of the other....