*nix: Ctrl+i interpreted as (Ctrl+)Tab in file lists

[Peter Mattern]

Opening dialog "Directory listing filters" by keyboard shortcut Ctrl+I triggers an "assertion failure" eventually followed by a core dump if an object was selected in the "detailed listing" of either local or remote pane before.

Steps to reproduce (see screenshot_main-window.png; terms according to ​https://wiki.filezilla-project.org/FileZilla_Client_Tutorial_(en)#Navigating_and_window_layout):
As long as objects are selected in the "directory tree" only like user directory "dummy" in the screenshot the said dialog behaves as expected. But as soon as an object in the "detailed listing" like folder "Musik" marked by a red asterisk in the screenshot gets selected by a single mouse click opening the dialog by keyboard shortcut Ctrl+I doesn't work any longer.
First a dialog "filezilla" (screenshot_dialogue-filezilla.png) comes up stating "An assertion failed". When "Continue" gets clicked FileZilla apparently continues to operate as usual. But clicking button "Stop" or hitting key "Esc" triggers a core dump.

It doesn't matter whether or not a connection is active. Opening the dialog from the menu, either by mouse or by keyboard mnemonics, isn't affected at all.

Up to date Arch Linux x86_64. FileZilla either 3.14.1 from the distribution's official repositories or SVN checkout 7250 compiled against libfilezilla 0.3.0 or SVN checkout 7250, same findings with all these variants.

Aside from the screenshots the "backtrace" provided by dialogue "filezilla" (backtrace_dialogue-filezilla.txt) as well as a backtrace generated by handing the saved core dump to gdb via sytemd's coredumpctl (backtrace_gdb.txt) are attached.

[Tim Kosse]

Lovely, looks like a bug in wxWidgets.

Something somewhere in wx generates wxNavigationKeyEvent::WinChange, yet wxWidgets does not know how to handle that flag in GTK+ builds.

[Tim Kosse]

Somehow when pressing Ctrl+i, a wxKeyEvent for WXK_TAB key is generated.

[Tim Kosse]

Please apply ​https://github.com/wxWidgets/wxWidgets/commit/6f5b629f2f55e57ca8b9412052cbd02d4609512b to your copy of wxWidgets.

[Peter Mattern]

Problem isn't fixed yet. Exactly when Ctrl+I triggered the assertion failure earlier it's simply non-functional right now.

Seen with wxWidgets 46953a1 compiled against GTK 2.24.29, libfilezilla and FileZilla Client 7253 on Arch Linux x86_64.

On a side note I checked the same combination of components compiling wxWidgets against GTK 3.18.6, too. This compromised the FileZilla Client GUI more or less completely. E. g. horizontal bars like the one between "directory tree" and "detailed listing" couldn't be moved vertically any longer such that those two components were more or less condensed into a single one.