The Bookmarks KRunner has several issues:
[ ] `BookmarksRunner::prep()` leaks a Signal/Slot connection each time the browser instance from the factory is reused
[ ] `BookmarksRunner::prep()` leaves a dangling pointer in case a new browser object is instantiated
Specific to the `Firefox` implementation of the `Browser` interface:
[ ] On each `prepare` call, a new FetchSqlite instance is created, the old one is leaked. This also causes some warnings:
> QSqlDatabasePrivate::removeDatabase: connection '.../.mozilla/.../places.sqlite' is still in use, all queries will cease to work.
> QSqlDatabasePrivate::addDatabase: duplicate connection name '.../.mozilla/.../places.sqlite', old connection removed.
[ ] On each `prepare` call, the creation of the FetchSqlite instance creates a temporary copy of the places.sqlite and favicon.sqlite databases. These are 20 MByte resp. 15 MByte.
The resource leaks should be fixed.
The temporary copies of the Sqlite databases are very likely unnecessary, and may even result in bad results. Sqlite3 databases are multi-process - see https://www.sqlite.org/lockingv3.html - and the readonly access required by the runner is even less critical. On the other hand, just copying the main database file without accompanying write-ahead-log may give bad results (i.e. while the wal is flushed/checkpointed to the main db file).
Note, apparently Firefox once used Exclusive mode for the database files, but apparently no longer does. Exclusive mode would have prohibited reads of the db file.