Closed
Bug 1033403
Opened 10 years ago
Closed 10 years ago
[Messages] We don't stop rendering if we tap "back" too soon
Categories
(Firefox OS Graveyard :: Gaia::SMS, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
2.0 S6 (18july)
People
(Reporter: julienw, Assigned: julienw)
References
Details
(Whiteboard: [p=1])
Attachments
(1 file)
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.
Assignee | ||
Comment 2•10 years ago
|
||
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.
Attachment #8449470 -
Flags: review?(azasypkin)
Assignee | ||
Updated•10 years ago
|
Blocks: sms-sprint-4
Whiteboard: [not-part-of-initial-sprint]
Assignee | ||
Updated•10 years ago
|
Status: NEW → ASSIGNED
Comment 3•10 years ago
|
||
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.
Attachment #8449470 -
Flags: review?(azasypkin) → review+
Assignee | ||
Updated•10 years ago
|
Blocks: sms-sprint-2.0S6
Whiteboard: [not-part-of-initial-sprint] → [p=1]
Assignee | ||
Updated•10 years ago
|
Target Milestone: --- → 2.0 S6 (18july)
Assignee | ||
Comment 4•10 years ago
|
||
Comment on attachment 8449470 [details] [review] Github PR Requesting review again for the latest changes. I added a separate commit to make things easier.
Attachment #8449470 -
Flags: review+ → review?(azasypkin)
Assignee | ||
Comment 5•10 years ago
|
||
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?
Flags: needinfo?(jelee)
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!
Flags: needinfo?(jelee)
Assignee | ||
Comment 7•10 years ago
|
||
(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 :)
Assignee | ||
Comment 8•10 years ago
|
||
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.
Flags: needinfo?(azasypkin)
Comment 9•10 years ago
|
||
Comment on attachment 8449470 [details] [review] Github PR r=me, thanks!
Attachment #8449470 -
Flags: review?(azasypkin) → review+
Flags: needinfo?(azasypkin)
Assignee | ||
Comment 10•10 years ago
|
||
master: 09642e74e250fbc62db860c808ef188628fca55d Thanks a lot !
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•