Change Details

The Bookmarks KRunner has several issues: [x] `BookmarksRunner::prep()` duplicates the Signal/Slot connection each time the browser instance from the factory is reused - D15306 [x] 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: > 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: [x] 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.

The Bookmarks KRunner has several issues: [x] `BookmarksRunner::prep()` duplicates the Signal/Slot connection each time the browser instance from the factory is reused - D15306 [x] The temporary directory for favicons is never cleared - D15391 Specific to the `Firefox` implementation of the `Browser` interface: [x] 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: > 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: [x] 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.

The Bookmarks KRunner has several issues: [x] `BookmarksRunner::prep()` duplicates the Signal/Slot connection each time the browser instance from the factory is reused - D15306 [x] The temporary directory for favicons is never cleared - D15391 Specific to the `Firefox` implementation of the `Browser` interface: [ x] 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: > 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: [x] 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.