972654 - [B2G][SMS] SMS or MMS conversation does not automatically scroll to show new messages if already being viewed

Status: RESOLVED DUPLICATE of bug 952526

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

Description

[Rachel Pribble [:rpribble]]

Attachment: NoAutoScroll

Description:
If the conversation is already being viewed, the message thread will not automatically scroll up to reveal any new messages received. The user rarely (1/10) sees a notification that a new message has been received. Device does vibrate with alert when this happens.

Repro Steps:
1) Updated buri to BuildID: 20140212004003
2) Tap the SMS icon
3) Start a new conversation with another device (device B)
4) Send a message from the device being tested (device A) to device B
5) Keep the conversation open on the screen on device A
6) Send multiple messages in the same conversation from device B to device A
6) Observe device A fail to scroll down automatically

Actual:
Conversation does not scroll automatically to show newly received messages, so user is not aware of them.

Expected:
Conversation scrolls automatically to show new messages.

Environmental Variables:
Device: buri v13 moz ril
BuildID: 20140212004003
Gaia: ce17d5eae7b1893ae4397c814b10ae598fcbdb58
Gecko: ab07e61c2eb0
Version: 28.0
Firmware Version: v1.2-device.cfg

Notes:

Repro frequency: 100%
Link to failed test case: 
See attached: Video

Comment 1

[Jason Smith [:jsmith]]

Oh man, I'd find this completely utterly annoying. This is asking for a support compliant.

Comment 2

[bhavana bajaj [:bajaj]]

Could this be an issue on the gecko side of scrollbars. We have seen a few bugs last week around scrollbar not showing up etc, not sure if its related. A regression window may be helpful here and i am sure its a recent one. 

Reg blocking, I agree if not fixed on the support complaints and it could be really annoying for an end user for a commonly used application like sms

Comment 3

[J Zimbrick]

This can be reproduced in 1.1, 1.2, and the earliest 1.3 with one extra step. 
After receiving a few messages on 1.1, and 1.2, the screen will start to scroll down automatically without user input to keep up with new messages. If you scroll back up, the only notification of new messages is the phone vibrating, the screen will no longer scroll automatically.

On the latest 1.3, following the repro steps will never scroll down automatically if there is no user input. However, if the user scrolls down at all, the phone seems to behave as it should, a pop-up appears saying that the user has received a new message and there is an option to scroll instantly down to read the new message.

So since there's some variation of this bug present on all branches I'm going to remove the regression tags, unless a regression window is wanted for when that pop-up functionality was added for 1.3? Would that be valuable info?

Latest 1.1 Environmental Variables:
Device: Buri
BuildID: 20140214041202
Gaia: c5cb252e5d1aa45d14f3a2ea182e73e2271e4496
Gecko: 2e2d6605f51d
Version: 18.0
Base Image: V1.2-device.cfg

Latest 1.2 Environmental Variables:
Device: Buri
BuildID: 20140214004001
Gaia: 539a25e1887b902b8b25038c547048e691bd97f6
Gecko: 2b2f4678f4cc
Version: 26.0
Base Image: V1.2-device.cfg

Oldest 1.3 Environmental Variables:
BuildID: 20130919040201
Gaia: 0dedb5b3789afc638a0c7c67652937fcb30e77d2
Gecko: 803189f35921
Version: 27.0a1
Base Image: V1.2-device.cfg

Latest 1.3 Environmental Variables:
BuildID: 20140214004001
Gaia: 22e065f75193f569a78a8ec827b08e1ed520e1b2
Gecko: e3766683210c
Version: 28.0
Base Image: V1.2-device.cfg

Comment 4

[Jason Smith [:jsmith]]

(In reply to J Zimbrick from comment #3)
> This can be reproduced in 1.1, 1.2, and the earliest 1.3 with one extra
> step. 
> After receiving a few messages on 1.1, and 1.2, the screen will start to
> scroll down automatically without user input to keep up with new messages.
> If you scroll back up, the only notification of new messages is the phone
> vibrating, the screen will no longer scroll automatically.
> 
> On the latest 1.3, following the repro steps will never scroll down
> automatically if there is no user input. However, if the user scrolls down
> at all, the phone seems to behave as it should, a pop-up appears saying that
> the user has received a new message and there is an option to scroll
> instantly down to read the new message.
> 
> So since there's some variation of this bug present on all branches I'm
> going to remove the regression tags, unless a regression window is wanted
> for when that pop-up functionality was added for 1.3? Would that be valuable
> info?

You are completely out in left field here - this is not the bug that's filed here. I want answers to the following questions:

1. Does the exact STR in the bug demonstrated by the video reproduce on 1.2 or not?
2. Why is rpribble claiming this doesn't reproduce on 1.2?
3. I want a re-clarification of what the bug is here - please re-summarize the problem.

Comment 5

[KTucker [:KTucker][Inactive 3/4/2016]]

In reply to comment 4

1. I could not reproduce this issue following the original steps written by RPribble on the buri v 1.2.0 Mozilla RIL.
2. Rpribble marked v 1.2.0 as unaffected because the message thread automatically scrolls down when a new SMS is received in a message thread that the user is currently viewing on v 1.2.0.  
3. On v 1.3.0, the message thread does not automatically scroll down to show the new SMS received in a message thread that the user is currently viewing. The user has to manually scroll down on the message thread to see that they have received a new SMS.

1. User A is viewing their conversation with User B in the SMS app.
2. User B sends another SMS to User A. 
3. The message thread does not automatically scroll down to show the new SMS from User B.
4. User A has to manually scroll down to see the new SMS from User B.

Comment 6

[Jason Smith [:jsmith]]

Okay - thanks for the clarification. So let's do the regression window following the specific STR in the bug originally.

Comment 7

[sarsenyev]

sounds like dupe of bug 952526

Comment 8

[Jason Smith [:jsmith]]

Looks like it - that should have been nominated from the very beginning.

Comment 9

[Julien Wajsberg [:julienw] (PTO -> Jul 24)]

Just a note: when I investigated bug 952526 initially, it happened only in very specific conditions, only when we had a new thread or opened a small thread (that would not initially scroll, so about 2 or 3 messages). That's also what the description in comment 0 is saying, and that's why I did not nominate this at the time.

Maybe we regressed more since then, I'll check while reviewing Gabriele's patch.

Comment 10

[Jason Smith [:jsmith]]

(In reply to Julien Wajsberg [:julienw] from comment #9)
> Just a note: when I investigated bug 952526 initially, it happened only in
> very specific conditions, only when we had a new thread or opened a small
> thread (that would not initially scroll, so about 2 or 3 messages). That's
> also what the description in comment 0 is saying, and that's why I did not
> nominate this at the time.
> 
> Maybe we regressed more since then, I'll check while reviewing Gabriele's
> patch.

That actually would still be pretty bad for a dogfooder. There's many cases where someone would start a SMS conversation & fill enough messages to cause scrolling to start - that breaks the continuous SMS conversation use case.

Comment 11

[Julien Wajsberg [:julienw] (PTO -> Jul 24)]

(In reply to Jason Smith [:jsmith] from comment #10)
> (In reply to Julien Wajsberg [:julienw] from comment #9)
> > Just a note: when I investigated bug 952526 initially, it happened only in
> > very specific conditions, only when we had a new thread or opened a small
> > thread (that would not initially scroll, so about 2 or 3 messages). That's
> > also what the description in comment 0 is saying, and that's why I did not
> > nominate this at the time.
> > 
> > Maybe we regressed more since then, I'll check while reviewing Gabriele's
> > patch.
> 
> That actually would still be pretty bad for a dogfooder. There's many cases
> where someone would start a SMS conversation & fill enough messages to cause
> scrolling to start - that breaks the continuous SMS conversation use case.

But moving back to the thread list and tap again to enter the thread would fix it. That fits the "easy workaround" check for me.

Comment 12

[Jason Smith [:jsmith]]

(In reply to Julien Wajsberg [:julienw] from comment #11)
> (In reply to Jason Smith [:jsmith] from comment #10)
> > (In reply to Julien Wajsberg [:julienw] from comment #9)
> > > Just a note: when I investigated bug 952526 initially, it happened only in
> > > very specific conditions, only when we had a new thread or opened a small
> > > thread (that would not initially scroll, so about 2 or 3 messages). That's
> > > also what the description in comment 0 is saying, and that's why I did not
> > > nominate this at the time.
> > > 
> > > Maybe we regressed more since then, I'll check while reviewing Gabriele's
> > > patch.
> > 
> > That actually would still be pretty bad for a dogfooder. There's many cases
> > where someone would start a SMS conversation & fill enough messages to cause
> > scrolling to start - that breaks the continuous SMS conversation use case.
> 
> But moving back to the thread list and tap again to enter the thread would
> fix it. That fits the "easy workaround" check for me.

And you would have to repeatedly do that. For every. Single. Message. That's literally going to blow someone's head up on level of annoyance, which is asking for a support compliant.

Comment 13

[Julien Wajsberg [:julienw] (PTO -> Jul 24)]

(In reply to Jason Smith [:jsmith] from comment #12)

> And you would have to repeatedly do that. For every. Single. Message. That's
> literally going to blow someone's head up on level of annoyance, which is
> asking for a support compliant.

No :) When I tested, the bug would not happen if the container already scrolls when you enter the thread. That's why I didn't nominate the bug.

But _that_ may have regressed, and I'm glad Gabriele fixed it anyway.

Comment 14

[Jason Smith [:jsmith]]

(In reply to Julien Wajsberg [:julienw] from comment #13)
> (In reply to Jason Smith [:jsmith] from comment #12)
> 
> > And you would have to repeatedly do that. For every. Single. Message. That's
> > literally going to blow someone's head up on level of annoyance, which is
> > asking for a support compliant.
> 
> No :) When I tested, the bug would not happen if the container already
> scrolls when you enter the thread. That's why I didn't nominate the bug.
> 
> But _that_ may have regressed, and I'm glad Gabriele fixed it anyway.

No - you are continuously missing the point here. The bad use case is talking about when the user has started with a thread that *isn't* scrollable, not the *scrollable* use case. That's going to literally blow someone's head up if this happens.

Comment 15

[Julien Wajsberg [:julienw] (PTO -> Jul 24)]

Yeah but what I mean is that the "continuous SMS conversation" that you're talking about will quickly push this thread to the "scrollable" use case.

As soon as the bug happens, it means the thread will be scrollable when we enter here.

So, yes, the bug would happen for each new thread, but it would quickly disappear. Not for "every single message" like you're saying.

Now let's stop this discussion, it doesn't matter who's right/wrong here, since it's been fixed and will be uplifted.