aboutsummaryrefslogtreecommitdiffstats
path: root/src/requestinterceptor.cpp
diff options
context:
space:
mode:
authorDanilo M. <danix@danix.xyz>2026-08-20 10:54:32 +0200
committerDanilo M. <danix@danix.xyz>2026-08-20 10:54:32 +0200
commit241cf9444b36c9f5217778759e98576dc21e58fa (patch)
tree88f27e582c0d8a69a5c34c95bc6eacc338536091 /src/requestinterceptor.cpp
parente4e2f4af71a6597548d2e35d82a5dec6a4ed3a5c (diff)
downloadqtmaildir-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 'src/requestinterceptor.cpp')
0 files changed, 0 insertions, 0 deletions