From 5de81471ebcac21dbf8c5d781cd1b5f1df931bb8 Mon Sep 17 00:00:00 2001 From: "Danilo M." Date: Mon, 3 Aug 2026 09:43:07 +0200 Subject: fix: render the message pane at all Clicking a thread left the pane blank. Two independent bugs, both from the same false premise: that setHtml() navigates to the base URL it is given. It does not. setHtml() navigates to a data: URL carrying the markup and applies the base URL afterwards, purely as the document's origin. Verified empirically on Qt 6.11. Built on that wrong assumption were: - MessagePage::acceptNavigationRequest compared the navigation's URL against documentUrl() and rejected everything else, so the document load was refused. It now accepts a typed main-frame navigation, which is one we initiated ourselves. - RequestInterceptor exempted exactly the qtmaildir: base URL and denied everything else, so the data: document load was blocked too. The interceptor fix is scoped to ResourceTypeMainFrame rather than allowing the data: scheme outright. A blanket allow would have been a real hole: a message body can write or an iframe, and the existing dataSchemeBlocked test in test_interceptor.cpp was right to fail when that was tried. Sub-resource data: URLs remain denied. Note this was never working. The drafted version had the same defect in a different spelling (it compared url.scheme() rather than the whole URL, and would have rejected the data: navigation just the same), and task 11 shipped with no runtime test to catch it. test_messageview.cpp now pins all three facts: the document loads, its text reaches the page, and a data: image inside a hostile body stays blocked. Co-Authored-By: Claude Opus 5 --- docs/manual-verification.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) (limited to 'docs/manual-verification.md') diff --git a/docs/manual-verification.md b/docs/manual-verification.md index 607d7e8..6683f6c 100644 --- a/docs/manual-verification.md +++ b/docs/manual-verification.md @@ -31,7 +31,7 @@ databases. | 1 | Startup shows no configuration warnings with a valid config | **FAIL, then fixed** | | 2 | `tag:inbox` count matches `notmuch count --output=threads` | **PASS** | | 3 | A large query paints the first rows within a second | **PASS** | -| 4 | A new query discards the running one's results | PENDING | +| 4 | A new query discards the running one's results | **PASS** | | 5 | A malformed query (`tag:`) reports an error and does not crash | **PASS, item reworded** | | 6 | Selecting a thread renders every message, oldest first | PENDING | | 7 | Unmatched messages appear as one-line stubs | PENDING | @@ -90,6 +90,16 @@ Query `*` over the whole database, 36,335 threads: The first screenful is available essentially immediately and the rest fills in behind, which is what the batching exists for. +## Item 4: PASS + +Typed `*`, then `tag:unread` while the first query was still filling. The +list switched cleanly to 136 unread threads with no leftover rows from the +41,000-thread result set and no wrong intermediate count. The generation +counter discards superseded batches as designed. + +The maintainer's note that `*` "loaded almost quicker than I could type" +matches the item 3 measurement: 21 ms to the first batch. + ## Item 5: PASS, but the item was wrong The checklist assumed `tag:` is malformed and should raise an error. It is -- cgit v1.2.3