| Summary: | "Save As..." dialog interprets certain user actions as "save in this directory" instead of "descend into this directory" | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kio | Reporter: | Szczepan Hołyszewski <rulatir> |
| Component: | Open/save dialogs | Assignee: | David Faure <faure> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | a.samirh78, bugs, esmb, kdelibs-bugs, meven29, nate, poprocks |
| Priority: | NOR | Keywords: | usability |
| Version: | 5.62.0 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | https://commits.kde.org/kio/6327a9f05eb242f0a5b3dd2b5deff370cfae9fa3 | Version Fixed In: | 5.69 |
| Sentry Crash Report: | |||
|
Description
Szczepan Hołyszewski
2019-10-08 18:44:50 UTC
It seems that grabbing the mouse is necessary in order to descend into a directory. It cannot be done with keyboard only. IMPORTANT CORRECTION (too bad it is impossible to edit the original post!!!!) The application I am experiencing the issue in is Chrome not Firefox, but more importantly, Chrome simply uses KDialog and the bug can be reliably reproduced with: kdialog --getsavefilename $HOME/index.html I can reproduce. KDE Plasma Version: 5.16.5, KDE Frameworks Version: 5.62.0, Qt Version: 5.13.1 Slackware Current using packages from AlienBob's "ktown" repo (which use little to no patching from upstream). This only seems to happen if there is a suggested filename. Eg, open PDF in Okular, try to save it to a different location. If the filename widget is blank, behaviour works as expected. Eg, fire up "kwrite", type a few letters, and hit Save As. *** Bug 409738 has been marked as a duplicate of this bug. *** *** Bug 410653 has been marked as a duplicate of this bug. *** I request changing severity to major. I agree with the reporter of the duplicate #410653 that this is "a major bug for all keyboard users". Regression from bea5b681 ? (In reply to Christoph Feck from comment #7) > Regression from bea5b681 ? Confirmed, by reverting it locally. The issue is that the condition in the if in KFileWidgetPrivate::_k_slotViewKeyEnterReturnPressed() : if (operationMode == KFileWidget::Saving && (ops->mode() & KFile::File) && ops->selectedItems().isEmpty()) { particularly the last bit, ops->selectedItems().isEmpty(): - navigate using keyboard arrows and select a dir - press Enter to open that dir - this newly opened dir has no selected items, so the condition evaluates to true, which saves the file and closes the dialogue altogether. Nice find. Would you be interested in submitting a patch? I am trying to make one. The issue I have identified, in some cases, is that KFileWidgetPrivate::_k_slotViewKeyEnterReturnPressed is called right after KDirOperator::Private::_k_slotActivated which changed the directory making the kdiroperator selection empty, making _k_slotViewKeyEnterReturnPressed calling _slotOk when it is called. _k_slotViewKeyEnterReturnPressed should not get called if _k_slotActivated has just changed directory. Git commit 816fc6f9444fe70cdddc67b94e8027fdaab99c20 by Méven Car. Committed on 04/12/2019 at 10:21. Pushed by meven into branch 'master'. [KFileWidget] Avoid calling slotOk right after the url changed Summary: When _k_slotViewKeyEnterReturnPressed is called, KDirOperator::_k_slotActivated is called first potentially opening another directory. And since the directory changed, the kdiroperator selection is empty, causing then kiowidgets-kdirmodeltest to call slotOk and if a filename was present in the filename field, it will cause the dialog to accept() prematurely. This patch prevents KDirOperator::keyEnterReturnPressed to be emitted when QAbstractItemView::activated would be, preventing the issue in the first place. FIXED-IN: 5.65 Relates to D19824 Test Plan: 1. Save a file using KFileWidget 2. Go to a folder with files and directories 3. Select a file 4. Select a directory 5. Hit Enter Before: The directory is opened briefly and the dialog returns. After: The selected directory is opened. Reviewers: #frameworks, ngraham, elvisangelaccio, dfaure Reviewed By: ngraham, dfaure Subscribers: ahmadsamir, feverfew, kde-frameworks-devel Tags: #frameworks Differential Revision: https://phabricator.kde.org/D25420 M +13 -10 src/filewidgets/kdiroperator.cpp M +0 -2 src/filewidgets/kdiroperator.h https://commits.kde.org/kio/816fc6f9444fe70cdddc67b94e8027fdaab99c20 *** Bug 417714 has been marked as a duplicate of this bug. *** I can still reproduce the original issue. :( Patch proposal: https://phabricator.kde.org/D27455 I can still reproduce: Operating System: Slackware Current KDE Plasma Version: 5.18.3 KDE Frameworks Version: 5.68.0 Qt Version: 5.13.2 Git commit 6327a9f05eb242f0a5b3dd2b5deff370cfae9fa3 by Méven Car. Committed on 04/04/2020 at 09:01. Pushed by meven into branch 'master'. FileWidgets: Ignore Return events from KDirOperator Summary: Activated event is used to handle key returns from KDirOperator. Making a Return in the KDirOperator would cause a double treatment of the event : - first KDirOperator::activated for the activated event - second KDirOperator::activated for the KeyPressEvent Key_Return FIXED-IN: 5.69 Test Plan: - Open Kate - Ctrl+Maj + S, to save file as - type a file name - go to a directory using the arrows keys and return key Before: The dialog returns immediately with the file name in the opened directory. After: The directory is opened, the user can continue specifying path. Reviewers: dfaure, ngraham, #frameworks Reviewed By: dfaure, ngraham Subscribers: ahmadsamir, kde-frameworks-devel Tags: #frameworks Differential Revision: https://phabricator.kde.org/D27455 M +7 -0 src/filewidgets/kfilewidget.cpp https://commits.kde.org/kio/6327a9f05eb242f0a5b3dd2b5deff370cfae9fa3 |