diff options
| author | Danilo M. <danix@danix.xyz> | 2026-08-20 10:54:32 +0200 |
|---|---|---|
| committer | Danilo M. <danix@danix.xyz> | 2026-08-20 10:54:32 +0200 |
| commit | 241cf9444b36c9f5217778759e98576dc21e58fa (patch) | |
| tree | 88f27e582c0d8a69a5c34c95bc6eacc338536091 /CHANGELOG.md | |
| parent | e4e2f4af71a6597548d2e35d82a5dec6a4ed3a5c (diff) | |
| download | qtmaildir-241cf9444b36c9f5217778759e98576dc21e58fa.tar.gz qtmaildir-241cf9444b36c9f5217778759e98576dc21e58fa.zip | |
docs: sharpen item 114 after a hand test on a loaded image
Not a regression and not something we removed: Save image is item 114,
still open. Item 127 removed Save LINK and deliberately left this one.
The circumstances the user reported sharpen it twice. The image had already
had its remote content loaded, so m_allowRemote was still true at the click.
That flag is live on the shared interceptor and cleared by the next
showThread(), so a download handler is subject to whatever it says at the
moment of the click rather than at render time. A naive handler therefore
looks perfect in exactly this case and fails once the grant is gone, which
makes "it worked when I tried it" worthless as evidence. The entry records
that both cases must be tested against a message whose grant has been
cleared.
The second is a corollary of item 127. downloadRequested is per-profile, so
connecting it lights up every download entry Chromium offers at once,
including the Save link just removed from the menu. An entry being absent
from a menu is not the same as the capability being absent, so the handler
must decide per request rather than merely exist.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YDq53rMd3AQp7QmcZzpuBM
Diffstat (limited to 'CHANGELOG.md')
0 files changed, 0 insertions, 0 deletions
