Opened 3 years ago

Last modified 3 years ago

#10723 reopened Bug report

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

Reported by: Peter Mattern Owned by: Tim Kosse
Priority: normal Component: FileZilla Client
Keywords: Cc:
Component version: 3.14.1, VCS Operating system type: Linux
Operating system version: Arch Linux

Description

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.

Attachments (4)

screenshot_main-window.png (16.4 KB) - added by Peter Mattern 3 years ago.
screenshot_dialogue-filezilla.png (9.8 KB) - added by Peter Mattern 3 years ago.
backtrace_dialogue-filezilla.txt (1.0 KB) - added by Peter Mattern 3 years ago.
backtrace_gdb.txt (4.0 KB) - added by Peter Mattern 3 years ago.

Download all attachments as: .zip

Change History (9)

Changed 3 years ago by Peter Mattern

Attachment: screenshot_main-window.png added

Changed 3 years ago by Peter Mattern

Changed 3 years ago by Peter Mattern

Changed 3 years ago by Peter Mattern

Attachment: backtrace_gdb.txt added

comment:1 Changed 3 years ago by Tim Kosse

Owner: set to Tim Kosse
Status: newaccepted

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.

comment:2 Changed 3 years ago by Tim Kosse

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

comment:3 Changed 3 years ago by Tim Kosse

Resolution: fixed
Status: acceptedclosed

comment:4 Changed 3 years ago by Peter Mattern

Resolution: fixed
Status: closedreopened

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.

comment:5 Changed 3 years ago by Tim Kosse

Summary: Core dump due to opening dialog "Directory listing filters" by keyboard shortcut*nix: Ctrl+i interpreted as (Ctrl+)Tab in file lists
Note: See TracTickets for help on using tickets.