*nix: Ctrl+i interpreted as (Ctrl+)Tab in file lists
|Reported by:||Peter Mattern||Owned by:||Tim Kosse|
|Component version:||3.14.1, VCS||Operating system type:||Linux|
|Operating system version:||Arch Linux|
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.