Broken threading after replying from Firefox

[sosnovsky]

Bug needs investigation: 1) I received message from User 1 addressed to me and another recipient User 2 2) I wrote reply and sent it with reply-all 3) Reply message is rendered in the same thread for me, but for User 1 and User 2 it created new thread 4) Next replies are rendered in the same thread, so only first one caused creating new thread

It's not clear why it happened, can be missing msgId or something else, so needs finding way to reproduce this bug.

[tomholub]

@martgil could you please see if you manage to somehow reproduce this issue? You'll need two different accounts

[tomholub]

This was observed for at least some of us on thread Re: Roman's email address question

[martgil]

@martgil could you please see if you manage to somehow reproduce this issue? You'll need two different accounts

Yes, Tom. Will do -- I will provide all the information once I have the result. I'll follow up here if I may have questions of any sort. thank you.

[martgil]

@sosnovsky I reviewed this bug report and unfortunately, I'm unable to replicate it as I get the expected result. In details, I reviewed the as User 3 (first-person perspective) as well as the User 2 (third-person perspective). In addition to this, we haven't received any bug reports via email.

User 3's perspective on Firefox:

User 2's perspective also on Firefox:

I only had to remove some emails from the screenshots.

[sosnovsky]

@martgil looks like this bug is quite random - I haven't found exact way of reproducing it, but it happened for me again a couple days ago. Also new thread was created for me, while in original description new thread was created for message recipients. I'll recheck message data for broken thread, trying to find what's wrong with it

[martgil]

Thanks @sosnovsky - Is there any chance that you have seen this bug when you are using a Google Chrome browser?

[sosnovsky]

Thanks @sosnovsky - Is there any chance that you have seen this bug when you are using a Google Chrome browser?

No, I think it happened only on Firefox for me - I mostly use FlowCrypt with Chrome, and haven't noticed such issue, but on Friday I tried to use Firefox when bug with reply buttons appeared and my sent message lead to broken threading there.

[martgil]

Hi @sosnovsky - I'm still unable to replicate this issue for some reason. I've sent a screen recording of what I have tried, and I hope it closely matches how you encountered the issue.

[martgil]

Some discussions we have that is worth checking.

Hi Mart,

Yes, described case sounds like a possible reason for this issue, I was thinking of this part - https://github.com/FlowCrypt/flowcrypt-browser/blob/b89fc546972e41b2788de520e53fd50ddd4a0c2b/extension/chrome/elements/compose-modules/compose-render-module.ts#L220

Maybe sometimes Firefox fails to correctly fetch this threadId and creates a new thread instead.

[martgil]

Hi @sosnovsky, I'm finally able to reproduce this issue on Firefox. As for my testing, the threadId becomes empty if the reply was then transposed into a draft and so sending it to as reply all will then make the reply to sent as a new thread.

View from the reciever's end:

(observe that normal replies goes into the same email thread while draft ones sent in a new thread)

Steps to reproduce (from original bug description above):

1) I received message from User 1 addressed to me and another recipient User 2 2) I wrote reply - leave the reply as is and make it as draft secure email 3) Access the draft once again and sent it with reply-all 3) Reply message is rendered in the same thread for me, but for User 1 and User 2 it created new thread 4) Next replies are rendered in the same thread, so only first one caused creating new thread

[sosnovsky]

Well done, thanks for checking it out 👍

[martgil]

Notes for me:

• In the ComposeView,replyMsgId and threadId differs when a composed reply turns into a draft message and access it later unlike directly composing a reply then sending the email. I think the correct behavior on this one is that, it should retain the correct replyMsgId as threadId... instead of new replyMsgId if I'm not mistaken and based on the data i've been debugging.

[martgil]

In further checking the reply that is transposed to a draft that we're later sent has no request header:

In-Reply-To and References...

[tomholub]

Well done triaging it!