Move in eeschema sometimes unexpectedly moves mouse cursor to bottom of screen

[MightyPork]

Pressing M to move a label or symbol in eeschema sometimes moves mouse cursor to the bottom edge of the screen. Sometimes the cursor immediately moves back, but my bottom taskbar still opens. Sometimes it stays there, like is shown in the attached video.

I can reliably reproduce it now, but it does not happen always. There's no errors or warnings printed to terminal.

see the attached screencast

Environment: KDE/Plasma on Arch Linux, X.org

Application: Eeschema
Version: (5.1.0-1415-g01e78b04c), release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.65.3 OpenSSL/1.1.1c zlib/1.2.11 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh2/1.8.2 nghttp2/1.36.0
Platform: Linux 5.2.3-arch1-1-ARCH x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
    Boost: 1.69.0
    OpenCASCADE Technology: 7.3.0
    Curl: 7.65.3
    Compiler: GCC 9.1.0 with C++ ABI 1013

Build settings:
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=OFF
    KICAD_USE_OCC=ON
    KICAD_SPICE=ON

[Jeff Young (jeyjey)]

Doesn't reproduce on OSX. Anyone seen this on MSW?

[Ian McInerney (imcinerney)]

I am not able to recreate this on my GTK build of master. I am using Mate on Fedora though, so it could be DM specific.

@MightyPork, Is there a specific set of actions that you use to recreate this?

Application: Eeschema
Version: (5.1.0-1416-g7bfbcef94), debug build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.65.3 OpenSSL/1.1.1c-fips zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.20.2 (+libidn2/2.0.5) libssh/0.9.0/openssl/zlib nghttp2/1.38.0
Platform: Linux 5.1.18-300.fc30.x86_64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
    Boost: 1.69.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.65.3
    Compiler: Clang 8.0.0 with C++ ABI 1002

Build settings:
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

[MightyPork (mighty-pork)]

I could reliably reproduce it, then restarted kicad and it stopped. But after some "M" pressing on different labels, it crashed.. sadly looks like I don't have debug symbols. Just pressing M and esc a few times on different labels and designators, and I reproduced it again.

Thread 1 "kicad" received signal SIGSEGV, Segmentation fault.
0x00007fffcd437607 in ?? () from /usr/bin/_eeschema.kiface
(gdb) bt
#0 0x00007fffcd437607 in () at /usr/bin/_eeschema.kiface
#1 0x00007fffcd437d7f in () at /usr/bin/_eeschema.kiface
#2 0x00007fffcd4dc907 in () at /usr/bin/_eeschema.kiface
#3 0x00007fffcd6a0490 in () at /usr/bin/_eeschema.kiface
#4 0x00005555556d2a41 in make_fcontext ()
#5 0x000015900000158f in ()
#6 0x0000159200001591 in ()
#7 0x00000000002088e0 in ()
#8 0x000000000002d461 in ()
#9 0x00007ffff6f0f2b0 in main_arena () at /usr/lib/libc.so.6
#10 0x00007ffff6f0f2b0 in main_arena () at /usr/lib/libc.so.6
#11 0x000055555a01de60 in ()
#12 0x000055

[MightyPork (mighty-pork)]

got a good trace for you, but it's likely a different bug. This happens when cancelling a move.

Thread 1 "kicad" received signal SIGSEGV, Segmentation fault.
SCH_EDIT_FRAME::PutDataInPreviousState (this=0x555556dd4be0, aList=0x0, aRedoCommand=false) at /home/ondra/packages/kicad-git/src/kicad-git/eeschema/schematic_undo_redo.cpp:266
266 for( int ii = aList->GetCount() - 1; ii >= 0; ii-- )
(gdb) bt
#0 0x00007fffcd2cf607 in SCH_EDIT_FRAME::PutDataInPreviousState(PICKED_ITEMS_LIST*, bool) (this=0x555556dd4be0, aList=0x0, aRedoCommand=false)
    at /home/ondra/packages/kicad-git/src/kicad-git/eeschema/schematic_undo_redo.cpp:266
#1 0x00007fffcd2cfd7f in SCH_EDIT_FRAME::RollbackSchematicFromUndo() (this=0x555556dd4be0) at /home/ondra/packages/kicad-git/src/kicad-git/eeschema/schematic_undo_redo.cpp:365
#2 0x00007fffcd374907 in SCH_MOVE_TOOL::Main(TOOL_EVENT const&) (this=0x555555cdb400, aEvent=...) at /home/ondra/packages/kicad-git/src/kicad-git/eeschema/tools/sch_move_tool.cpp:434
#3 0x00007fffcd538490 in std::function<int (TOOL_EVENT const&)>::operator()(TOOL_EVENT const&) const (__args#0=..., this=0x555555e0d6c8) at /usr/include/c++/9.1.0/bits/std_function.h:685
#4 0x00007fffcd538490 in COROUTINE<int, TOOL_EVENT const&>::callerStub(long) (aData=<optimized out>) at /home/ondra/packages/kicad-git/src/kicad-git/include/tool/coroutine.h:335
#5 0x00005555556d2a41 in make_fcontext ()
#6 0x0000000000000000 in ()
(gdb)

I can reproduce the mouse moving bug, but it's not consistent. Some labels seem more prone to it, some move the cursor to the side of the label (instead of to the center, as I think is intended).

I verified that it is independent on zoom and pan. There's error logs when it happens.

[MightyPork (mighty-pork)]

oops i meant to say: There's NO error logs when it happens. Why doesn't launchpad have comment editing ...

[Jeff Young (jeyjey)]

The crash is happening because the <esc> tries to undo the action and there has been no undo record stacked. This very well may be the same fault: that is, due to some event order specific to GTK the move is starting before any items have been selected. So the mouse jumps to an unknown location, and the undo doesn't get stacked.

Sadly, I can't reproduce either, so I'm only guessing.

[Jeff Young (jeyjey)]

I've added some defensive code which should at least prevent the crash (though it does nothing for the underlying cause).

[KiCad Janitor (kicad-janitor)]

Fixed in revision b6b26b4e1ebaec13ae7baa83d459f17b2bbd8415
https://git.launchpad.net/kicad/patch/?id=b6b26b4e1ebaec13ae7baa83d459f17b2bbd8415

[Ian McInerney (imcinerney)]

Ok, after some playing around with it I have been able to get this behavior in a specific case: when you try to move text where the reference point is off-screen.

For instance: put a net label halfway on-screen (so the net connection point is off-screen), then use M to move it. My mouse cursor immediately jumps to the bottom of the screen.

@Jeff, I have not tried the fix you pushed, so I don't know if that would affect this.

I am currently running:
Application: Eeschema
Version: (5.1.0-1416-g7bfbcef94), debug build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.65.3 OpenSSL/1.1.1c-fips zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.20.2 (+libidn2/2.0.5) libssh/0.9.0/openssl/zlib nghttp2/1.38.0
Platform: Linux 5.1.18-300.fc30.x86_64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
    Boost: 1.69.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.65.3
    Compiler: Clang 8.0.0 with C++ ABI 1002

Build settings:
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

[Ian McInerney (imcinerney)]

Ok, it seems to be caused by the reference point being off-screen which means when the cursor is warped to it the display has no idea what to do.

I think the fix for this is to simply enable warping of the display so the desired cursor position is centered in the view. The attached patch does that.

[Jeff Young (jeyjey)]

Ian's steps /do/ reproduce on OSX, so perhaps this isn't GTK-specific.

[KiCad Janitor (kicad-janitor)]

Fixed in revision ce7833b982b1ab869005b465055fcbc356c4c6b6
https://git.launchpad.net/kicad/patch/?id=ce7833b982b1ab869005b465055fcbc356c4c6b6

[Jeff Young (jeyjey)]

I don't understand how it worked before when the worldCoords param was defaulting to false.

But the patch works, so I've merged it.

[MightyPork (mighty-pork)]

Can't reproduce anymore, I think it's fixed.

Application: Eeschema
Version: (5.1.0-1426-g120637bd9), release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.65.3 OpenSSL/1.1.1c zlib/1.2.11 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh2/1.8.2 nghttp2/1.36.0
Platform: Linux 5.2.3-arch1-1-ARCH x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
    Boost: 1.69.0
    OpenCASCADE Technology: 7.3.0
    Curl: 7.65.3
    Compiler: GCC 9.1.0 with C++ ABI 1013

Build settings:
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=OFF
    KICAD_USE_OCC=ON
    KICAD_SPICE=ON

[Ian McInerney (imcinerney)]

@Jeff, I was just playing with this test case in the 4 editors (eeschema, libedit, pcbnew and modedit), and we have some inconsistent behavior.

Here is what happens if I move an item whose reference point is offscreen:
pcbnew: Mouse pointer stays in place, item doesn't move until the first mouse movement at which point the referene point is moved to the mouse position
modedit: Same as pcbnew
libedit: Mouse pointer stays in place and the item's reference point is immediately moved to it
eeschema: View is warped so the mouse pointer is on the reference point & it is in the middle of the screen

We should probably choose one behavior and use it in all the tools.

[MightyPork (mighty-pork)]

@Ian

Just tested this and the behavior is inconsistent even if the item is on-screen.

Pcbnew has the correct behavior I think: mouse warps to the reference point and the item is not moved until I move my mouse, at which point the move is relative to the original position.

In symbol editor the object is warped to the mouse cursor, that's never what I want.

Eeschema gets this almost right, but the item is moved - aligned - if it was previously off-grid (i.e. grid became coarser).

[Jeff Young (jeyjey)]

You can make them consistent my changing the preference in Eeschema. However, we should probably add the preference to Pcbnew as well....