The Bookmarks KRunner has several issues:

• BookmarksRunner::prep() duplicates the Signal/Slot connection each time the browser instance from the factory is reused - D15306
• The temporary directory for favicons is never cleared - D15391

Specific to the Firefox implementation of the Browser interface:

• The runner returns duplicate matches, typically one match with a title, and one or more matches without title - D15357
• On each prepare call, a new FetchSqlite instance is created, the old one is leaked. This also causes some warnings: - D16409, D16410

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.

Specific to the Chrome implementation of the Browser interface:

• The database scheme is queried for each result icon, although fixed - D15488, D15489, D15490, D15491

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.