diff options
| author | Danilo M. <danix@danix.xyz> | 2026-08-03 09:54:26 +0200 |
|---|---|---|
| committer | Danilo M. <danix@danix.xyz> | 2026-08-04 12:52:55 +0200 |
| commit | 75974dd47b43ef41eb9bda1a0ab011fd796aeda4 (patch) | |
| tree | 7a331f28508d5be2569c011b05b998f86c7ddff6 /tests/test_keymap.cpp | |
| parent | 2ca7ba8642e81e400a8f3145a15e3f6328b36a28 (diff) | |
| download | qtmaildir-75974dd47b43ef41eb9bda1a0ab011fd796aeda4.tar.gz qtmaildir-75974dd47b43ef41eb9bda1a0ab011fd796aeda4.zip | |
fix: drop cached remote images when switching threads
Granting remote content on one thread, moving to another and coming back
showed the images again with the banner gone. The grant is documented as
never sticky, and it was not: verified against a local HTTP server that the
image is fetched exactly once, under the grant, and never re-requested. The
interceptor's policy was correct throughout and allowRemote was false on
return.
The images came from the engine's decoded-image cache, which is keyed on
the document and consulted before any request exists, so the interceptor is
never asked. Policy right, pane lying.
clearHttpCache() empties the profile's store but not that one. Loading
about:blank first discards the previous document along with its cached
images. This belongs in showThread() rather than render(): render() also
runs for the remote-content grant itself, where throwing the document away
would discard exactly what the user just asked to see.
Found by the task 13 checklist (item 11) and confirmed fixed by the
maintainer on screen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Diffstat (limited to 'tests/test_keymap.cpp')
0 files changed, 0 insertions, 0 deletions
