Crash when using Super+RMB to resize Discord client

[kode54]

Describe the bug
When I use the default configuration bind of Super+RMB to resize Discord, as of 80569f4, it crashes in the same place consistently.

To Reproduce
Steps to reproduce the behavior:

1. Use mostly default configuration with Xwayland-hidpi-xprop and wlroots-hidpi-xprop patches applied, and scale factor of 2.
2. Start Discord with Wayfire session
3. Super+RMB increase the size of the window
4. Wayfire crashes in the same place every time

Expected behavior
Window should resize, without crashing due to this dereference.

Screenshots or stacktrace
Stack trace:

Core was generated by `wayfire'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00005e54c22016f8 in operator() (__closure=<optimized out>, data=0x5e54c3fd1dc0)
    at ../src/core/seat/input-method-relay.cpp:27
27                  auto surface = wf::node_to_view(focus)->get_keyboard_focus_surface();
[Current thread is 1 (Thread 0x71737ac2a9c0 (LWP 362016))]
(gdb) bt
#0  0x00005e54c22016f8 in operator() (__closure=<optimized out>, data=0x5e54c3fd1dc0)
    at ../src/core/seat/input-method-relay.cpp:27
#1  std::__invoke_impl<void, wf::input_method_relay::input_method_relay()::<lambda(void*)>&, void*>
    (__f=<optimized out>) at /usr/include/c++/13.2.1/bits/invoke.h:61
#2  std::__invoke_r<void, wf::input_method_relay::input_method_relay()::<lambda(void*)>&, void*>
    (__fn=<optimized out>) at /usr/include/c++/13.2.1/bits/invoke.h:111
#3  std::_Function_handler<void(void*), wf::input_method_relay::input_method_relay()::<lambda(void*)> >::_M_invoke(const std::_Any_data &, void *&&) (__functor=<optimized out>, __args#0=<optimized out>)
    at /usr/include/c++/13.2.1/bits/std_function.h:290
#4  0x00005e54c21bf71e in std::function<void (void*)>::operator()(void*) const
    (__args#0=<optimized out>, this=<optimized out>) at /usr/include/c++/13.2.1/bits/std_function.h:591
#5  wf::wl_listener_wrapper::emit (data=<optimized out>, this=<optimized out>)
    at ../src/wl-listener-wrapper.tpp:57
#6  wf::handle_wrapped_listener (listener=<optimized out>, data=<optimized out>)
    at ../src/wl-listener-wrapper.tpp:10
#7  0x000071737ba6901e in wl_signal_emit_mutable (signal=<optimized out>, data=0x5e54c3fd1dc0)
    at ../wayland-1.22.0/src/wayland-server.c:2241
#8  0x000071737af31596 in ffi_call_unix64 () at ../src/x86/unix64.S:104
#9  0x000071737af2e00e in ffi_call_int
    (cif=cif@entry=0x7ffcae704d50, fn=<optimized out>, rvalue=<optimized out>, avalue=<optimized out>, closure=closure@entry=0x0) at ../src/x86/ffi64.c:673
#10 0x000071737af30bd3 in ffi_call
    (cif=cif@entry=0x7ffcae704d50, fn=<optimized out>, rvalue=rvalue@entry=0x0, avalue=avalue@entry=0x7ffcae704e20) at ../src/x86/ffi64.c:710
#11 0x000071737ba67ada in wl_closure_invoke (closure=closure@entry=0x5e54c3a56a90, target=<optimized out>,
    target@entry=0x5e54c409cdb0, opcode=opcode@entry=1, data=<optimized out>,
    data@entry=0x5e54c3db3a70, flags=2) at ../wayland-1.22.0/src/connection.c:1025
#12 0x000071737ba6c180 in wl_client_connection_data
    (fd=<optimized out>, mask=<optimized out>, data=<optimized out>)
    at ../wayland-1.22.0/src/wayland-server.c:438
#13 0x000071737ba6aae2 in wl_event_loop_dispatch (loop=0x5e54c29b4cc0, timeout=timeout@entry=-1)
    at ../wayland-1.22.0/src/event-loop.c:1027
#14 0x000071737ba6b2d7 in wl_display_run (display=0x5e54c29b4bd0) at ../wayland-1.22.0/src/wayland-server.c:1493
#15 0x00005e54c21bdd06 in main (argc=<optimized out>, argv=<optimized out>) at ../src/main.cpp:418

Wayfire version
wayfire-hidpi-xprop-git 0.8.0.r118.g80569f47-1

[kode54]

Further notice, it doesn't seem to happen if I'm doing it while no apps are being launched by session startup. So perhaps it's happening due to resizing while input focus is being stolen by something. I really want to enable the input focus steal prevention plugin, but I forget which plugin it is, or where to get it.

[ammen99]

I did notice the line which causes this and was wondering how come there are no crashes happening because of it :P

Will be fixed soon.

[ammen99]

Oh wait this is the very same issue as #2175 and is fixed by #2188 :)