1033403 - [Messages] We don't stop rendering if we tap "back" too soon

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::SMS, defect)

Description

[Julien Wajsberg [:julienw]]

I noticed this while working on bug 1022755.

If we press "back" very quickly after entering a thread, we don't stop rendering.

One visible consequence is bug 1022755 that we'll fix differently.
Another less visible consequence is that we consume CPU and memory.

Comment 1

[Julien Wajsberg [:julienw]]

Attachment: Github PR

WIP, I still need to write unit tests

Comment 2

[Julien Wajsberg [:julienw]]

Comment on attachment 8449470 [details] [review]
Github PR

Hey Oleg, can you check this?

There are 2 commits, but the first commit is bug 1022755 so please review only the second commit.

Once I land bug 1022755 (hopefully soon ;) ) I'll rebase and have only one commit.

Comment 3

[Oleg Zasypkin [:azasypkin]]

Comment on attachment 8449470 [details] [review]
Github PR

Looks good! Just left few nits ragarding to unit tests and one question about marking thread as read in case of quick leaving of the thread panel.

Comment 4

[Julien Wajsberg [:julienw]]

Comment on attachment 8449470 [details] [review]
Github PR

Requesting review again for the latest changes.

I added a separate commit to make things easier.

Comment 5

[Julien Wajsberg [:julienw]]

Hey Jenny,

we have a UX question we can't decide here.

Here are the steps:
1. the user taps on a thread with unread messages to display it
2. he presses "back" even before anything is displayed yet

=> Should the thread still be "unread" ?

I can see 2 sides:
* if nothing has been displayed, it's not really "read"
* but it could be a quick gesture to mark the thread "read" without actually reading it

So it's really correctness vs ease of use. I'm leaning towards the ease of use (so second behavior), but until now the first behavior was used.

What do you think?

Comment 6

[Jenny Lee]

Hello Julien,

Can we improve the performance to avoid delayed content display ;)? 

I can't really think of under what circumstances would someone want to press "back" right before reading the content. Maybe the user selected one message thread and realized that's not the one he's looking for right away and wanted to go back? or he somehow mistouch the back button (For the case you described, we have the freshly implemented select items mode for that which will make mark as read a lot easier. If there's only like 1 or 2 message user wants to mark, he'll just have to wait a few seconds till the content is displayed which in my opinion is fine). 

That being said, I do prefer 2nd behavior for a different reason. Whenever user tap on a thread with unread message, whether or not the entire content is displayed yet, the thread will be marked as read. I think this makes things easier, it is clear that user made the attempt to open and potentially read a message thread, if he chooses to go back immediately (and he has to be real quick), we don't have to remind him the message is still unread. Same happens in email too. Thanks!

Comment 7

[Julien Wajsberg [:julienw]]

(In reply to Jenny Lee from comment #6)
> Hello Julien,
> 
> Can we improve the performance to avoid delayed content display ;)?

There will always be a gap so...

> 
> I can't really think of under what circumstances would someone want to press
> "back" right before reading the content.

As I said, this could be an habit he has: he doesn't really want to read the message but merely mark it as a read. TBH I do this ;)

> That being said, I do prefer 2nd behavior for a different reason. Whenever
> user tap on a thread with unread message, whether or not the entire content
> is displayed yet, the thread will be marked as read. I think this makes
> things easier, it is clear that user made the attempt to open and
> potentially read a message thread, if he chooses to go back immediately (and
> he has to be real quick), we don't have to remind him the message is still
> unread. Same happens in email too. Thanks!

Thanks, this is clear :)

Comment 8

[Julien Wajsberg [:julienw]]

Comment on attachment 8449470 [details] [review]
Github PR

Ok Oleg, I think it's ready.

I merged the previous follow-up with the new one, because the previous was made invalid by your comment.

I saw a weird behavior happening because of this issue, with these STR:
1. open a big thread
2. immediately press back
3. open another thread (preferably a small one so that you can tell the difference)
4. see that the messages from the big thread are added.

Comment 9

[Oleg Zasypkin [:azasypkin]]

Comment on attachment 8449470 [details] [review]
Github PR

r=me, thanks!

Comment 10

[Julien Wajsberg [:julienw]]

master: 09642e74e250fbc62db860c808ef188628fca55d

Thanks a lot !