Blank database name causes secret service to fail

[tscheiby]

Have you searched for an existing issue?

• [x] Yes, I tried searching and reviewed the pinned issues

Brief Summary

When Database name is not set, every(?) access (e.g. Kmail) to Database leads to asking to create new database. Setting it remedies the problem.

Steps to Reproduce

1. go to Database Settings -> general -> Database-Metadata
2. delete anything entered in databasename
3. save it
4. In a terminal start dbus-monitor --session "interface='org.freedesktop.Secret.Service'"
5. quit and start kmail
6. outputs something like this
7. method call time=1753602642.140474 sender=:1.77 -> destination=org.freedesktop.secrets serial=388 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=ReadAlias string "default" method call time=1753602642.144594 sender=:1.77 -> destination=org.freedesktop.secrets serial=391 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=ReadAlias string "default" method call time=1753602642.225652 sender=:1.79 -> destination=org.freedesktop.secrets serial=2323 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=CreateCollection array [ dict entry( string "org.freedesktop.Secret.Collection.Label" variant string "XXX" ) ] string "" and it prompts you to create a new Database
8. entering anything as Database Name remedies this

Expected Versus Actual Behavior

User should be forced to enter a Database Name as soon as Secret-Service-Integration is activated if not already set.

KeePassXC Debug Information

Operating System

Linux

Linux Desktop Environment

KDE

Linux Windowing System

Wayland

[droidmonkey]

Possibly related to #10761

[rocketraman]

I have this issue as well, the first time on every reboot / startup of KDE Plasma.

Access to the secret service via the CLI secret-tool works fine. But anything Chromium based (like Slack, Chrome, and so on) pops open a dialog box to create a new database, even though the current already open database is where the secret service is running. When canceling that dialog box, the requesting service continues with a failure to retrieve credentials (which is highly annoying as almost every single site needs to be logged into again).

The workaround is to turn off the secret service and then turn it back on again -- this fixes the problem, so it eems like something becomes corrupted/broken in KeepassXC on initial startup. Perhaps there is a timing issue / race condition with KeepassXC startup and the initial credentials requests from the system which breaks something?

I guess my issue is not exactly the same as described here though, because my "Database name" field has a value.