search

keepassxreboot / keepassxc

KeePassXC is a cross-platform community-driven port of the Windows application “Keepass Password Safe”.
https://keepassxc.org/
Other
21.34k stars 1.47k forks source link

Cannot type into search field after first start of KeepassXC #5608

Closed imp1sh closed 3 years ago

imp1sh commented 4 years ago

When I start KeepassXC and unlock the database I cannot search in it. I hit CTRL + F or I click with mouse into search field. Then I cannot enter any string whatsoever. When I close Keepass and restart / unlock it again it works again. But the first time after system boot it always fails to work

Steps to Reproduce

Expected Behavior

I should be able to search but I'm not.

Context

I experienced this phenomena on two different computers, both installed freshly with Fedora 33.

KeePassXC - Version 2.6.1 Revision: 9a35bba

Qt 5.15.1 Diagnosemodus ist deaktiviert.

Betriebssystem: Fedora 33 (Workstation Edition) CPU-Architektur: x86_64 Kernel: linux 5.8.16-300.fc33.x86_64

Aktivierte Erweiterungen:

Kryptographische Bibliotheken: libgcrypt 1.8.6

Operating System: Fedora 33 Desktop Env: Gnome Windowing System: Wayland

droidmonkey commented 4 years ago

Screenshot when it's not working please

imp1sh commented 4 years ago

Here you go. keepass_not_search_possible

droidmonkey commented 4 years ago

Seems like the field is enabled and focused. You cannot type into it at all? This is definitely not reproducible on any of my machines.

imp1sh commented 4 years ago

No, I cannot type at all, no matter if I klick into the field nor when I hit CTRL + F. It must have something to do with changes with Fedora 33. KeepassXC act strangely.

rodmcrae commented 4 years ago

I'm also having trouble with search, on Debian 10 (stable). I can type into the search field, but nothing comes up - totally disfunctional search. I'm sure this was working before, though I haven't used Keepassxc before, only Keepassx. Strangely, I have the same issue in Keepassx (I have both installed).

droidmonkey commented 4 years ago

Nothing was changed with search in 2.6.2 that would cause this behavior.

stinos commented 4 years ago

Related (perhaps): when hiding the toolbar or even changing the window size so that the search field is not visible, search functionality is disabled, i.e. Ctr-F does nothing. As a result if you change settings to have the toolbar show both icons and text, search is possible only when making the window wide enough. Note that when the window is large enough and you start typing in the search field, but then shrink the window to make the field disappear, the search field is even though hidden still active because typing text does alter search results, until pressing Esc.

phoerious commented 4 years ago

That is somewhat of a Qt bug and we may need to develop a workaround for it.

stinos commented 4 years ago

I assume Ctrl-F is implemented as 'move keyboard focus to search textbox' somewhere, and that doesn't work if textbox isn't visible? Niceset fix would probably be something along the lines of displaying a popup/overlay with the search box upon Ctrl-F.

droidmonkey commented 4 years ago

That issue is tracked elsewhere

stinos commented 4 years ago

Sorry didn't find this at first; here it is though: #505

imp1sh commented 4 years ago

If can do anything to resolve this issue just tell me.

finderAUT commented 4 years ago

I am experiencing the same issue on Fedora 33 but it is not just limited to the search input field but also the ones of e.g. add entry

Edit: However input to the password field works (seemingly always). KeeShare signee input field only sometimes (probably depending where the focus was when opening settings window, also not working after switching to some other app and back)

KeePassXC - Version 2.6.2 Revision: e9b9582

Qt 5.15.1 Diagnosemodus ist deaktiviert.

Betriebssystem: Fedora 33 (Workstation Edition) CPU-Architektur: x86_64 Kernel: linux 5.8.16-300.fc33.x86_64

Aktivierte Erweiterungen:

Kryptographische Bibliotheken: libgcrypt 1.8.6

droidmonkey commented 4 years ago

The only common denominator amongst all you folks (besides KeePassXC) is Fedora 33.

droidmonkey commented 4 years ago

I loaded a Fedora 33 instance with XFCE and could not reproduce this problem.

imp1sh commented 4 years ago

I use Gnome with Wayland. Maybe Wayland is the reason idk. I have couple of other different issues actually. Sometimes it's not possible to paste a password into keepassxc. Also the ALT + TAB issue for which I made a ticket. Don't know if they are related though.

finderAUT commented 4 years ago

I loaded a Fedora 33 instance with XFCE and could not reproduce this problem.

Probably is a Gnome/Wayland issue .... it works with Xorg.

droidmonkey commented 4 years ago

@imp1sh if you are having all those issues it is definitely a Wayland issue, perhaps even a qt5-wayland platform issue.

imp1sh commented 4 years ago

Where to put this then? I have not experienced any issues with other applications so far, only keepassxc. @finderAUT Xorg is no longer being maintained.

droidmonkey commented 4 years ago

Are you running kpxc with wayland or using xwayland? QT_QPA_PLATFORM should be set to wayland.

imp1sh commented 4 years ago

I don't know how to check this. I haven't made any manual changes to the base system of Fedora 33.

scandinave commented 3 years ago

Hi, I'm on fedora 33 and also have the bug. Start KPXC with the option -platform waylandseem to resolve the problem. Set the QT_QPA_PLATFORM environment variable to wayland too.

agittins commented 3 years ago

I'm experiencing the same symptoms as @finderAUT, in that no input fields respond to keyboard input, with the exception of the password fields (but only when they are in hidden-mode and even then, intermittently). Widgets do receive focus (they get highlights around them) on mouse actions, and context menus work (including pasting text) but they don't respond to keyboard actions, including Ctrl-V or TAB.

Per @imp1sh 's experience, if I close and re-start kpxc, things appear to work OK - although I get no caret showing in single-line text inputs, but typing works (the "notes" multiline widget seems to work fine - caret and input ok).

I'm using Debian sid and i3wm. I think this started happening after I did a system upgrade (and it was a big one that included qt and a million other things!) but I don't recall if it was the same time that I updated kpxc or not from 2.5ish - it also coincides with moving to a new machine, so I'm clearly not optimising for reduced variables over here! :-)

I have kpxc starting automatically from my i3 config, so it could be a race condition, which might explain why the second launch works. picom (my compositor) launches before it, but maybe it's still setting up and causes an issue. I'm running Xorg.

I haven't noticed issues in any other Qt apps, and in fact the caret issue doesn't seem to be a problem in them, either. I've tried qjackctl, qmidiroute and vlc and text input works fine on those.

KeePassXC - Version 2.6.2
Revision: e9b9582

Qt 5.15.1
Debugging mode is disabled.

Operating system: Debian GNU/Linux bullseye/sid
CPU architecture: x86_64
Kernel: linux 5.9.0-4-amd64

Enabled extensions:
- Auto-Type
- Browser Integration
- SSH Agent
- KeeShare (only unsigned sharing)
- YubiKey
- Secret Service Integration

Cryptographic libraries:
 libgcrypt 1.8.7

If there's more I can do to help narrow down the culprit let me know.

muety commented 3 years ago

Got the same problem on Fedora 33 and latest Gnome.

fazuuuu commented 3 years ago

Same issue on fedora 33, using gnome on wayland.

rtoepfer commented 3 years ago

I'm having the same issue on Fedora 33. I've done a full dnf install update. At times I'm unable to enter via the keyboard. Its not always on initial application start. The bug also occurs after switching applications. To fix I don't have to close the entire application but just close the database and then reopen the database. I'm using kdbx database format.

KeePassXC - Version 2.6.4 Revision: 34a78f0

Qt 5.15.2 Debugging mode is disabled.

Operating system: Fedora 33 (Workstation Edition) CPU architecture: x86_64 Kernel: linux 5.10.16-200.fc33.x86_64

Enabled extensions:

Cryptographic libraries:

imp1sh commented 3 years ago

What is the next step? Do you need any more input from us users? I think the bug is easy to reproduce in contrast to the issues flag. I myself has witnessed this behaviour on every single installation which are about four so far.

droidmonkey commented 3 years ago

I just installed Fedora 33 in a VM, using GNOME and Wayland, installed KeePassXC from the store, created a new database, unlocked.... and no problems searching. Enabled start on login, logged out and back in, unlocked DB and no problems searching. Nothing for us to fix here unfortunately.

image

imp1sh commented 3 years ago

That's weird. It happens, I can promise you that. What can I do to narrow it down? Strace? Debug Symbols? I don't know what to do. Is this maybe an issue for some other party?

droidmonkey commented 3 years ago

File a bug report with qt under the qt5wayland module: https://bugreports.qt.io I won't do it because I cannot reproduce the problem.

auzias commented 3 years ago

Hi, same issue for me. On Fedora 33 with Wayland too.

The ugly work-around I found is to use the mouse in the search field on the loop icon and two-click on enable/disable Case sensitive. It works sometimes with just one click.

KeePassXC - Version 2.6.4
Revision: 34a78f0

Qt 5.15.2
Debugging mode is disabled.

Operating system: Fedora 33 (Workstation Edition)
CPU architecture: x86_64
Kernel: linux 5.10.20-200.fc33.x86_64

Enabled extensions:
- Auto-Type
- Browser Integration
- SSH Agent
- KeeShare (signed and unsigned sharing)
- YubiKey
- Secret Service Integration

Cryptographic libraries:
- libgcrypt 1.8.7
droidmonkey commented 3 years ago

Can someone post a screen capture video of the behavior?

droidmonkey commented 3 years ago

Can someone confirm if they have anything related to "deepin" installed on their systems? Apparently deepin-qt5-integration causes significant issues with every single Qt app if it is installed.

See writeup for a similar issue plaguing a Manjaro user: https://github.com/keepassxreboot/keepassxc/issues/6277#issuecomment-801436082

droidmonkey commented 3 years ago

I just confirmed that installing any of these packages (then restarting) causes the input fields of KeePassXC to be almost unusable:

image

After removing those packages and doing sudo dnf remove deepin*, I restarted KeePassXC and everything worked normally again.

imp1sh commented 3 years ago

[jochen@localhost ~]$ rpm -aq|egrep -i 'deepin|qt5'|sort adwaita-qt5-1.2.0-1.fc33.x86_64 dbusmenu-qt5-0.9.3-0.25.20160218.fc33.x86_64 libaccounts-qt5-1.16-2.fc33.x86_64 libadwaita-qt5-1.2.0-1.fc33.x86_64 phonon-qt5-4.11.1-6.fc33.x86_64 phonon-qt5-backend-gstreamer-4.10.0-4.fc33.x86_64 polkit-qt5-1-0.113.0-5.fc33.x86_64 poppler-qt5-0.90.0-6.fc33.x86_64 qt5-qtbase-5.15.2-2.fc33.x86_64 qt5-qtbase-common-5.15.2-2.fc33.noarch qt5-qtbase-gui-5.15.2-2.fc33.x86_64 qt5-qtdeclarative-5.15.2-2.fc33.x86_64 qt5-qtgraphicaleffects-5.15.2-2.fc33.x86_64 qt5-qtlocation-5.15.2-2.fc33.x86_64 qt5-qtmultimedia-5.15.2-2.fc33.x86_64 qt5-qtquickcontrols2-5.15.2-2.fc33.x86_64 qt5-qtquickcontrols-5.15.2-2.fc33.x86_64 qt5-qtsensors-5.15.2-2.fc33.x86_64 qt5-qtspeech-5.15.2-2.fc33.x86_64 qt5-qtspeech-speechd-5.15.2-2.fc33.x86_64 qt5-qtsvg-5.15.2-2.fc33.x86_64 qt5-qttools-common-5.15.2-2.fc33.noarch qt5-qttools-libs-designer-5.15.2-2.fc33.x86_64 qt5-qtwayland-5.15.2-3.fc33.x86_64 qt5-qtwebchannel-5.15.2-2.fc33.x86_64 qt5-qtwebkit-5.212.0-0.53.alpha4.fc33.x86_64 qt5-qtx11extras-5.15.2-2.fc33.x86_64 qt5-qtxmlpatterns-5.15.2-2.fc33.x86_64 qt5-srpm-macros-5.15.2-1.fc33.noarch qtlockedfile-qt5-2.4-33.20150629git5a07df5.fc33.x86_64 qtsingleapplication-qt5-2.6.1-40.fc33.x86_64 quazip-qt5-0.7.6-9.fc33.x86_64

auzias commented 3 years ago

I remove the deepin's, it works like a charm so far.

Thank you !

@droidmonkey, by curiosity, could you tell us how you find it ?

droidmonkey commented 3 years ago

Wasn't me! It was a fellow community member. See my comment about this a couple spots up.

finderAUT commented 3 years ago

Like @imp1sh I don't have any deepin packages installed. Did someone already file a QT bug?

I also tried to reproduce it in a VM but so far didn't succeed.

droidmonkey commented 3 years ago

These packages are the source of the problem for @imp1sh. I installed qtsingleapplication-qt5, rebooted, and the problem appeared immediately. qtlockedfile-qt5 comes along with it and should also be uninstalled.

qtlockedfile-qt5-2.4-33.20150629git5a07df5.fc33.x86_64
qtsingleapplication-qt5-2.6.1-40.fc33.x86_64

@Germano0 can we get these two packages removed from the Fedora repositories? They are deprecated all over the Qt5 space and negatively impact user experience.

https://fedora.pkgs.org/32/fedora-x86_64/qtsingleapplication-qt5-2.6.1-38.fc32.x86_64.rpm.html

There is an updated version of this that seems to be maintained and maybe deployed instead: https://github.com/itay-grudev/SingleApplication

For some reason qtsingleapplication-qt5 requires qtlockedfile-qt5, but there is no actual dependency there. The only package requiring qtlockedfile-qt5 is vacuum-im.

Germano0 commented 3 years ago

@droidmonkey there are no such dependencies in keepassxc https://src.fedoraproject.org/rpms/keepassxc/blob/rawhide/f/keepassxc.spec

droidmonkey commented 3 years ago

This is not a dependency in KeePassXC, this is a package that causes negative behavior in KeePassXC because it modifies the Qt5 environment.

imp1sh commented 3 years ago

Thank you so much for the hint @droidmonkey. I have just deinstalled those packages and I will report if they solve the problem. It looks like those were packages were installed as a dependency for smplayer and mpv.

Germano0 commented 3 years ago

@droidmonkey in order to start a discussion in Fedora development community to ask for removal of those two Qt libraries, I need detailed infos about. Where is stated in official Qt docs, that they are deprecated? Thank you

rtoepfer commented 3 years ago

I do not have deepin*, qtlocked or qtsingleapp packages on my default Fedora 33 install and I am still having issues.

Its been a few years since I've been working fully on Linux. Is there a static linked KeePassXC available? What about another way of packaging the dependencies along with KeePassXC itself?

On Tue, Mar 23, 2021 at 6:14 PM pmisch @.***> wrote:

Thank you so much for the hint @droidmonkey https://github.com/droidmonkey. I have just deinstalled those packages and I will report if they solve the problem. It looks like those were packages were installed as a dependency for smplayer and mpv.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/keepassxreboot/keepassxc/issues/5608#issuecomment-805341948, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGKROAKZRLITZIFUC7PVK3TFEOFLANCNFSM4S5OWYBA .

droidmonkey commented 3 years ago

@Germano0 I may be a bit premature to request removal, but something with Fedora, Wayland, and these qt5 libraries is causing major problems.

@rtoepfer you'll have to figure out perhaps yet another package that is causing similar interference. You can build your own keepassxc as static, but I don't think that would help anyway since the system libraries seem to be pulled in no matter what. I recommend using the appimage distribution instead.

muety commented 3 years ago

I've been following this discussion for a while. I'd like to report that I have neither of those Qt packages installed, but the issue is still occurring on my system.

holdenSK commented 3 years ago

can confirm - this happens on fedora 33 not only after first start, but after db is locked when minimized and opened after that.

droidmonkey commented 3 years ago

I did some more debugging and found that this only happens when KeePassXC starts on login. Once I quit and reopen KeePassXC then the issue is not present, even with the above applications installed. Can you confirm this behavior @ladislavfurman and @muety?

finderAUT commented 3 years ago

I can confirm that for me it only happens when KeePassXC autostarts on login. If I (re)start it manually it's fine.

Removing qtlockedfile-qt5-2.4-33.20150629git5a07df5.fc33.x86_64
qtsingleapplication-qt5-2.6.1-40.fc33.x86_64 which came as dependency of texstudio didn't help. Don't know why but there is a diff in the naming "qtsingleapplication-qt5 -0"

$ dnf repoquery --whatdepends qtlockedfile-qt5-2.4-33.20150629git5a07df5.fc33.x86_64  
qtlockedfile-qt5-devel-0:2.4-33.20150629git5a07df5.fc33.i686
qtlockedfile-qt5-devel-0:2.4-33.20150629git5a07df5.fc33.x86_64
qtsingleapplication-qt5-0:2.6.1-40.fc33.x86_64
qtsinglecoreapplication-qt5-0:2.6.1-40.fc33.x86_64
vacuum-im-0:1.3.0-0.20.20200608gitb6c5dad.fc33.x86_64

$  dnf repoquery --whatdepends qtsingleapplication-qt5-0:2.6.1-40.fc33.x86_64 --userinstalled
texstudio-0:3.1.1-1.fc33.x86_64

Other qt5 packages I have installed which differ from a fresh Fedora 33 install + dnf upgrade:

poppler-qt5-0.90.0-6.fc33.x86_64
python3-pyqt5-sip-4.19.24-1.fc33.x86_64
python3-qt5-5.15.0-4.fc33.x86_64
python3-qt5-base-5.15.0-4.fc33.x86_64
python-qt5-rpm-macros-5.15.0-4.fc33.noarch
qt5-qtconnectivity-5.15.2-2.fc33.x86_64
qt5-qtlocation-5.15.2-2.fc33.x86_64
qt5-qtmultimedia-5.15.2-2.fc33.x86_64
qt5-qtscript-5.15.2-2.fc33.x86_64
qt5-qtsensors-5.15.2-2.fc33.x86_64
qt5-qtserialport-5.15.2-2.fc33.x86_64
qt5-qttools-common-5.15.2-2.fc33.noarch
qt5-qttools-libs-designer-5.15.2-2.fc33.x86_64
qt5-qttools-libs-help-5.15.2-2.fc33.x86_64
qt5-qtwebchannel-5.15.2-2.fc33.x86_64
qt5-qtwebsockets-5.15.2-2.fc33.x86_64
qt5-srpm-macros-5.15.2-1.fc33.noarch
qtlockedfile-qt5-2.4-33.20150629git5a07df5.fc33.x86_64
qtsingleapplication-qt5-2.6.1-40.fc33.x86_64
droidmonkey commented 3 years ago

Those packages might be totally unrelated to the problem, I may have not been testing correctly given the autostart finding.