Always use the local cached copy first

[jasperweiss]

I think this is similar to #373 but as of 1.53.154 KeePassium should support background refresh.
However, I still often run into a situation where I want to autofill something and KeePassium says "Downloading database file.." which then stays stuck on 0% because internet connectivity is poor. I thought the new release was supposed to use the local copy on startup and perform the fetch in the background?
When there is no internet (as in airplane mode), KeePassium opens up the local copy right away but with internet, it will try to load the online version at startup. This is quite annoying when internet isn't working (imagine being on a captive portal, or a concrete building with poor mobile data connectivity trying to enter your WPA enterprise credentials, which you need to get from KeePassium)

Would it be possible to really only retrieve the online copy in the background? Such that the "downloading database file.." screen is gone altogether during startup and autofill? Cancelling the manual refresh (if it's stuck due to poor internet) should maybe also not discard the local copy and just direct back to the opened database instead of it being closed.

I use the direct connection to OneDrive, if that matters.

[keepassium]

I thought the new release was supposed to use the local copy on startup and perform the fetch in the background?

Not quite.

Background refresh introduced in 1.53 applies when you switch to KeePassium from other apps, when KeePassium already has a database loaded. It does not fetch the database in background, it only checks if the remote file is different from the loaded version — and offers a one-button manual reload if so. Which triggers the full fetch, decryption and caching.

Background refresh does not apply to the initial loading, which always fetches the remote database. It also does not apply to AutoFill at all — because AutoFill always launches zero, it's not possible to "switch back" to it.

Would it be possible to really only retrieve the online copy in the background?

This would not help too much in AutoFill… If it starts with the local cached copy, you would be done with AutoFill long before it manages to fetch anything in background.

---

Regarding the delay, there is already an existing mechanism to avoid delays on slow connections:

If your database is on a slow online storage, AutoFill may take a long time. You can improve AutoFill latency by forcing it to use the cached copy of the database:

• Consider File Unreachable → Immediately
• If File is Unreachable → Use Local Copy

You can also use a 1-second delay to give it a chance to actually fetch the database when there is a fast connection.

Give it a try and if something does not work right there, we can fine-tune that. But rebuilding the whole architecture of working with files (i.e. "start with remote") is unlikely to happen.

P.S. I think this is indeed a duplicate of #373.

[jasperweiss]

Background refresh introduced in 1.53 applies when you switch to KeePassium from other apps, when KeePassium already has a database loaded.

Ah that makes sense. This helps to prevent version conflicts whereas the way I envisioned it would only cause more version conflicts (which I assume is why the local copy is read-only)

there is already an existing mechanism to avoid delays on slow connections

Ah yes, the database settings. With auto-open it's something you easily forget exists ^_^

So I set the timeout to 1 second and it seems it does not actually timeout after 1 second, but after a full minute or so (in the app itself and autofill). Tapping 'cancel' does not seem to do anything. I'd expect that to just skip through to the local copy straight away.
Setting it to immediately does work though. But 1 second would indeed be better.

So in conclusion, Consider File Unreachable does not seem to do anything unless it is set to immediately and tapping cancel does not work either. Again, using the direct OneDrive connection. (To test this I broke my internet by setting the DNS to localhost, but the same thing happens when my train goes underground)

[keepassium]

@jasperweiss , sorry for the slow response.

Based on your feedback, I have created two issues: one for the timeout being broken, and one to manually switch to local copy when database loading takes too long. This should help both with the original issue (being stuck waiting for database) and the broken workaround I suggested :)

However, the suggestion to start with the cached copy and loading the remote DB in background will not be worked on. (As I mentioned, it would go against a key assumption in app architecture, which is too complicated to change at this stage.) So I'll close this as "won't fix" and we can focus on the two issues above.