LibWebView+UI: Add browsing history and rich address bar autocomplete

[awesomekling]

This branch adds a SQLite-backed HistoryStore in LibWebView that persists visited pages along with their title, favicon, visit count, and last-visit time. WebContentClient now records navigations, title changes, and favicon updates into the store, and a "Clear browsing history" action is wired up in the Privacy settings page.

The address bar autocomplete pipeline has been reworked so that suggestions are structured rows, history hits, a "Search with" entry, and plain completions, each carrying a title, URL, and subtitle rather than a flat string.

Both the Qt and AppKit UIs render the new rich rows with favicons and subtitles.

This is all pretty simple and barebones! There's plenty more data we could track and plenty more UI we could build on top of it, but we gotta start somewhere. :)

[trflynn89]

Super cool :)

I went through this a bit quickly. Some of it kinda hard to review where things are added to the history store in one commit and then removed or reshaped in the next commit, but 🤷‍♂️

Thinking out loud, I'm wondering if our monolith Ladybird.db makes sense long term, or if we want to split it out into Cookies.db, History.db, etc.? (This can be decided after merging)

[jdahlin]

A couple of things related SQLite and comparison with other browsers:

1. Favicon storage: Favicons are base64 TEXT inline in the History table. Firefox/Chrome store BLOBs in a separate database. Alternatively, don't SELECT favicon in the search query, instead fetch lazily after ranking.
2. Autocomplete full table scan: search_entries computes searchable_url via nested SUBSTR/INSTR/LIKE per row. No index can help here, instead a stored+indexed searchable_url column would turn this into an index range scan.
3. No frecency: Ranking by visit_count DESC means a page visited 100 times six months ago beats one visited 3 times today. Firefox/Chrome use a recency-weighted score as the primary sort key.
4. Per-statement auto-commit: A page load triggers up to 3 separate fsyncs (record_visit, update_title, update_favicon). Wrapping per-navigation writes in a single BEGIN/COMMIT would avoid that.

Not suggesting all of these should be fixed in this PR, but the current implementation will be too slow at some point when the history grows.

[awesomekling]

Thinking out loud, I'm wondering if our monolith Ladybird.db makes sense long term, or if we want to split it out into Cookies.db, History.db, etc.? (This can be decided after merging)

Moved this to History.db right away. It just makes sense :)

[awesomekling]

A couple of things related SQLite and comparison with other browsers:

1. Favicon storage: Favicons are base64 TEXT inline in the History table. Firefox/Chrome store BLOBs in a separate database. Alternatively, don't SELECT favicon in the search query, instead fetch lazily after ranking.

2. Autocomplete full table scan: search_entries computes searchable_url via nested SUBSTR/INSTR/LIKE per row. No index can help here, instead a stored+indexed searchable_url column would turn this into an index range scan.

3. No frecency: Ranking by visit_count DESC means a page visited 100 times six months ago beats one visited 3 times today. Firefox/Chrome use a recency-weighted score as the primary sort key.

4. Per-statement auto-commit: A page load triggers up to 3 separate fsyncs (record_visit, update_title, update_favicon). Wrapping per-navigation writes in a single BEGIN/COMMIT would avoid that.

Not suggesting all of these should be fixed in this PR, but the current implementation will be too slow at some point when the history grows.

All good points that we can and should address! ... but let's do it separately 😅