[iOS/Safari] No passwords filled in after selection

[akuropka]

[iOS/Safari] No passwords filled in after selection

[keepassium]

Thank you, Andreas. It is hard to say whether the issue on KeePassium's or on system's side. That is, whether the system even starts the AutoFill process…

But just to check for possible delays on KeePassium's side:

• Do you use a local database? (Based of #337, I assume yes)
• How long does it normally take to unlock the database?
• Does it work normally (immediately) if you tap the "key" button instead of the suggested account?

[akuropka]

Yes, local database is used.
It goes very fast... within less a second I would say.
If I select the key then I get other suggestions if available but selecting them brings the same issue.

It doesn't happen always but with time it is some sort of annoying.

Edit: Sonetimes the database(s) cannot opened in the app. Maybe this is related? Please see the screenshots.

[keepassium]

Thank you for the details and sorry for the slow response.

Sometimes the database(s) cannot opened in the app. Maybe this is related?

Yes, this would explain why nothing happens. I guess, the AutoFill is waiting for the file longer than the system is willing to wait for AutoFill, so after a few seconds the system terminates the AutoFill.

A good diagnostic step would be to reduce the DB loading timeout: open the app → navigate to Databases → long-press the database → Database Settings → in the "AutoFill" section, set "Consider file unreachable" to something like 1 or 5 seconds. This way, if Quick AutoFill fails to load the database, ahem, quickly, it will show the AutoFill dialog with more visual feedback about the process. It will probably still fail, but at least with some message.

This issue, however, raises two additional questions:

• Why it takes so long to read a local file. This sounds awfully similar to #109. Do you happen to have a network share (SMB server) added to the Files app?
• Why the cached file (.latest.kdbx) is not found. The only explanation I can think of is that in-app backups are disabled in app settings. Is this the case?

[akuropka]

Thank you for your reply. Long story short...

• Yes, I have network shares configured in the Files App and I know about the delays. Based on screenshots I was not connected to the local network. But since the issue that time was fixed I am wondering if this is an regression?
• Yes, backups are disabled. Since I am using the database only local and in read-only there are no backups needed in my case.

[keepassium]

But since the issue that time was fixed I am wondering if this is an regression?

I'm afraid this is just another facet of the same issue. The freezing was caused by system's "bookmark resolution" call, which is responsible for locating files stored outside of app sandbox. (This step is required by system's security restrictions.) This call is supposed to return quickly, but takes forever when there is an unreachable SMB server in Files. Since the underlying system issue cannot be fixed on the app side, the "fix" were just a series of workarounds to reduce problem's impact on usability.

• The first one treated the symptom: instead of freezing for a minute, the UI remained responsive and DB loading would be cancelled after a few seconds.
• The second one allowed loading of internal files that can be found and used without the "bookmark resolution" step.
• The third one was just a speed-up for bookmark resolution in "untroubled" conditions; it proved problematic and was reverted a month later.

So when the user opens KeePassium, the app can find and load an internal database (the one in On My iPhone / KeePassium) without touching any of the "frozen" system APIs. Everything looks fine.

The problem is that unlike the main app, AutoFill cannot skip bookmark resolution step, because the main app's Documents folder is not a local folder for AutoFill. For system, the folder with the database is internal for the app, but external for the AutoFill. Without bookmark resolution, AutoFill would be unable to see local files of the app (as happened recently, see #338).

And since AutoFill cannot avoid the problematic system call, it cannot get access to the database and stops after a timeout. If you enable backups, the AutoFill should fall back to loading a backup file (which avoids problematic calls) and theoretically should work.

[akuropka]

I see Apple makes it complicated to develop a solution aside of their own (however, that I never used).

In the past months I started to use StrongBox on another device (with same setup and file - database saved locally, using readonly, no backups). It has here and there some other issues but it seems they've been avoiding those difficulties with Apple here present.

[keepassium]

The last time I checked, StrongBox AutoFill always used an internal cached copy of the database. (Here's Mark attesting to the fact in 2021, and outlining the challenges of accessing local files from AutoFill.)

While one cannot run StrongBox in debugger (its repo is non-compilable), I did just re-check the code and AutoFill does seem to still rely on cached databases.

You can also verify this directly: when you transfer an updated database to the phone, the file shown in SB AutoFill won't update until you launch the main SB app.

In contrast, KeePassium AutoFill does attempt to work with the original database first, and only then falls back to cached copy (aka "latest backup"). It's just KeePassium offers the option to disable backup (aka caching) — and you did disable it — whereas StrongBox just caches databases without asking. For a fair comparison, you would need to enable backup in KeePassium.