Is your feature request related to a problem? Please describe.
MailFlow's current conversation threading groups replies and allows a thread to be expanded as sub-rows in the message list. This works well for browsing, but the reading pane still shows one selected message at a time.
For longer conversations, reading the full exchange requires repeatedly selecting individual sub-rows, and the surrounding context is no longer visible in the reading pane. Users who prefer a flat message list also cannot enable a full conversation reading pane independently of list grouping.
Describe the solution you'd like
Extend the current boolean conversation-threading preference into three modes:
- Off: preserve the flat message list and single-message reading pane.
- Grouped list: preserve the current behavior, with replies grouped and expandable in the message list.
- Conversation pane: keep conversations grouped in the list and display the complete chronological conversation in the reading pane when a thread is opened.
In conversation-pane mode:
- Show every message in the thread as a collapsible message card.
- Initially expand the newest message and keep older messages collapsed.
- Load each message body only when first expanded.
- Include sent replies and other thread members already returned by the thread endpoint.
- Preserve per-message reply, forward, star, unsubscribe, attachment, and header actions.
- Keep collapsed content inaccessible to keyboard and assistive technologies.
- Use restrained expand/collapse transitions and respect reduced-motion preferences.
The existing threadedView boolean could be migrated to an explicit mode while preserving current user behavior. If full-conversation counts need to include messages outside the currently selected folder, the backend could receive the selected mode explicitly while retaining the existing folder-scoped behavior for grouped-list mode.
Describe alternatives you've considered
- Keep only the current inline list expansion. This preserves the existing UI but does not provide a continuous reading experience.
- Always show full conversations in the reading pane. This would be disruptive for users who prefer single-message reading.
- Assemble conversations only from messages already loaded by the frontend. This can produce incomplete conversations and inaccurate counts across folders.
Additional context
This is related to, but not a duplicate of, #157. That issue fixed sent replies missing from the existing thread endpoint; this request concerns an optional full-conversation reading experience and configurable presentation modes.
I have a working proof of concept in a fork, including backend and frontend tests. Before preparing a clean PR from the latest main, I would like to confirm whether this UX and API direction fits the project. I am also happy to split the work into smaller focused PRs if preferred.
Is your feature request related to a problem? Please describe.
MailFlow's current conversation threading groups replies and allows a thread to be expanded as sub-rows in the message list. This works well for browsing, but the reading pane still shows one selected message at a time.
For longer conversations, reading the full exchange requires repeatedly selecting individual sub-rows, and the surrounding context is no longer visible in the reading pane. Users who prefer a flat message list also cannot enable a full conversation reading pane independently of list grouping.
Describe the solution you'd like
Extend the current boolean conversation-threading preference into three modes:
In conversation-pane mode:
The existing
threadedViewboolean could be migrated to an explicit mode while preserving current user behavior. If full-conversation counts need to include messages outside the currently selected folder, the backend could receive the selected mode explicitly while retaining the existing folder-scoped behavior for grouped-list mode.Describe alternatives you've considered
Additional context
This is related to, but not a duplicate of, #157. That issue fixed sent replies missing from the existing thread endpoint; this request concerns an optional full-conversation reading experience and configurable presentation modes.
I have a working proof of concept in a fork, including backend and frontend tests. Before preparing a clean PR from the latest
main, I would like to confirm whether this UX and API direction fits the project. I am also happy to split the work into smaller focused PRs if preferred.