diff options
| author | Danilo M. <danix@danix.xyz> | 2026-08-24 10:45:32 +0200 |
|---|---|---|
| committer | Danilo M. <danix@danix.xyz> | 2026-08-24 10:45:32 +0200 |
| commit | 22f01049b03f3a6bbe0455f96105a73d37abb3ee (patch) | |
| tree | 6c25a41f43acc1d4bf5d7d831590e05eb60f6151 /tests/test_htmlbuilder.cpp | |
| parent | df5f64f16359c9e34d258758f174187ffc618101 (diff) | |
| download | qtmaildir-22f01049b03f3a6bbe0455f96105a73d37abb3ee.tar.gz qtmaildir-22f01049b03f3a6bbe0455f96105a73d37abb3ee.zip | |
fix(messageview): drop the receive-only ribbon when the pane is blanked
MessageView::clear() resets the blocked-content bar, the stale notice and
the attachment bar by hand, and forgot the receive-only ribbon. Only
setReceiveOnlyAccount() ever hid it, and that is reached from
updateComposeActions(), which runs on a SELECTION change.
So the ribbon survived every route to a blank pane that is not one:
clear_pane, clear_selection, a new query, and a multi-row selection. It sat
over a blank pane, or over another account's mail, naming an account that
was no longer on screen and contradicting the live Reply button beside it.
Worth recording because it cost a test: the first one written for this
selected receive-only mail and then mail from a sending account, which is
how the report reads. It passed against the unfixed code, because that
gesture is precisely the one path that was already covered. The test now
drives clear_pane and a new query as well.
Its own trap, in the test rather than the code: clear_pane leaves the row
CURRENT, so re-selecting it emits no change and the ribbon is never
re-raised. The test moves away and back instead.
Diffstat (limited to 'tests/test_htmlbuilder.cpp')
0 files changed, 0 insertions, 0 deletions
