[Bug] Received reply displays quoted previous message instead of the actual new message body
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 1k
- Forks
- 348
- Avg merge
- 12h 28m
- Merged PRs (30d)
- 91
Description
Steps to reproduce
- Send a message to a system that includes the original message when replying. In this case the reply was generated by Stripe/Salesforce.
- Receive the reply.
- Open it in Nextcloud Mail.
- Nextcloud displays the body of the quoted previous message instead of the new reply.
- Use «View source» or download the .eml.
- The raw message contains the correct new reply before the quoted previous message.
- Open the same IMAP message in Thunderbird.
- Thunderbird displays the new reply correctly.
Expected behavior
Nextcloud Mail should display the new, non-quoted portion of the received message as the message body.
Actual behavior
Nextcloud Mail displays content from the quoted previous message and hides the actual newly received reply.
Mail app version
5.11.5
Nextcloud version
33.0.8 / Nextcloud AIO v13.6.0
Mailserver or service
No response
Operating system
No response
PHP engine version
None
Nextcloud memory caching
No response
Web server
None
Database
None
Additional info
A newly received reply is displayed with the body of the previous message instead of the actual new reply.
The message itself was synchronized correctly. The raw message source in Nextcloud Mail contains the correct new reply, followed by the quoted previous message.
Thunderbird displays the exact same IMAP message correctly.
In Nextcloud Mail:
sender, recipient, timestamp and subject belong to the newly received message
the displayed body is taken from the previous quoted message
the actual new body is not shown
The downloaded .eml confirms that the new body is present and occurs before the quoted previous message in both the text/plain and text/html MIME alternatives.
MIME structure:
multipart/mixed
└── multipart/alternative
├── text/plain
│ ├── actual new reply
│ └── quoted previous message
└── text/html
├── actual new reply
└── quoted previous message
I was able to create an anonymized standalone reproducer based on the affected message.
The anonymized .eml preserves the relevant MIME structure and contains an explicit new reply followed by an older quoted message.
Expected visible body:
This is the actual NEW content of the received reply.
The quoted section later in the message contains:
This is the OLD, quoted message text.
I imported this anonymized .eml into a normal IMAP folder and opened it in Nextcloud Mail. Nextcloud Mail reproducibly displays the OLD quoted message as the visible body instead of the new reply.
Thunderbird displays the same anonymized .eml correctly.
This reproduces independently of the original Stripe message and independently of the original mailbox state.
One possibly relevant detail is that the HTML part of the quoted previous message contains another complete ... document.
nextcloud-mail-anonymized-repro.eml
This therefore does not appear to be an IMAP synchronization or UID issue. The correct raw message is available to Nextcloud Mail, but the wrong part of its content is rendered as the visible body.
This may be related to #12811.
I also have #13590 open for a separate IMAP UID/cache issue, but based on the raw source this appears to be a different problem.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by importing the linked anonymized .eml and comparing how Nextcloud Mail renders its text/plain and text/html alternatives with Thunderbird. Trace the message-body rendering entry point and MIME quoted-content handling; done means the new reply is displayed while the older quoted message remains excluded.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- frontend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100