988726 - sms message thread is all wrong - wrong messages, wrong contacts, wrong header

Status: RESOLVED WORKSFORME

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

Description

[Dietrich Ayala (:dietrich)]

Master (1.5), Nexus 4, build from 3/24.

Screenshot attached.

STR:

1. see notification of sms, open it

Expected: Thread has correct contact in header, correct messages in content

Actual: In the screenshot, the header is contact A, the message is from contact B, and just outside the screenshot I scrolled up and saw a message from a different thread with contact C.

Comment 1

[Dietrich Ayala (:dietrich)]

Attachment: Screenshot 2014-03-26 22.38.36.png

Comment 2

[Dietrich Ayala (:dietrich)]

Hm, there's the screenshot, but not very useful with the personal information blocked out. Not that it'd be much useful not blocked out.

Julien & Steve, let me know if you want a copy of the db again.

Comment 3

[Steve Chung [:steveck]]

Same question: is it reproducible all the time or just once? Is all the notification you opened will lead you to the wrong thread or just it just happen on certain contact?

Comment 4

[Julien Wajsberg [:julienw]]

Dietrich, also, next time, would be useful if you could check the logcat for any error :)

I think I saw something like this once, but happens very rarely. Not sure at all what the reason could be, and pretty sure bug 881469 would help with edge cases like this (if this happens rarely of course).

Comment 5

[Anthony Ricaud (:rik)]

I'm also seeing that a lot with a build from a week or two.

Comment 6

[Julien Wajsberg [:julienw]]

Anthony, if you can find a reliable STR, would be nice :)

Comment 7

[Anthony Ricaud (:rik)]

The closest I can find for STRs is this:

With buggy phone, phone A and phone B:
1) Be sure that you have existing threads on buggy phone with phone A and phone B
2) On buggy phone, open thread with phone A
3) On buggy phone, go to homescreen
4) Lock buggy phone
5) On phone B, send a text to buggy phone
6) On buggy phone, tap the notification

This is not 100% reproducible. Maybe it works better with a reference workload.

This also looks similar to bug 952524.

Comment 8

[Julien Wajsberg [:julienw]]

One think that comes to my mind is the facebook datastore handling.

A good way to know whether there is a facebook datastore is to debug into the sms app and run this in the console:

navigator.getDataStores('Gaia_Facebook_Friends').then(function success(ds) {console.log('datastores:', ds); if (ds.length) { return ds[0].getLength(); } else { return Promise.reject('no datastore') }}).then(function(number) {console.log('nb friends:', number)}).catch(function error(err) {console.error('error', err); });

My output is:

"datastores:" Array [ DataStore ]
"nb friends:" 0

Comment 9

[Anthony Ricaud (:rik)]

So I do have 1 datastore. And it only contains an object:
|{ operation: "clear" }|

Comment 10

[Anthony Ricaud (:rik)]

Dietrich: Have you synced Facebook contacts? If no, could you run the instruction in comment 8 to see if that's a pattern?

Comment 11

[Dietrich Ayala (:dietrich)]

I have not synced Facebook contacts.

Comment 12

[Anthony Ricaud (:rik)]

So can you run the instruction in comment 8? :)

Comment 13

[Dietrich Ayala (:dietrich)]

Sorry, I missed that!

Output is:

"datastores:" Array [ DataStore ]
"nb friends:" 1

Does that mean I did FB sync at some point?

Comment 14

[Julien Wajsberg [:julienw]]

Yes, I think so, otherwise you'd have 0 like me.

So we may have a pattern here :)

NI me to try again after syncing some facebook friends.

Comment 15

[Julien Wajsberg [:julienw]]

Attachment: script to iterate the facebook datastore

Comment 16

[Julien Wajsberg [:julienw]]

Dietrich, can you please run the attached js file in the scratchpad, and copy paste the output you get in the console?

I think the object you have will be:

  "data >" Object { byTel: Object, treeTel: Array[0] }

Thanks :)

Comment 17

[Anthony Ricaud (:rik)]

My output:
"task >" Object { operation: "clear" } Scratchpad/1:11
"task >" Object { operation: "add", id: 1, data: Object } Scratchpad/1:11
"data >" Object { byUid: Object, byTel: Object, treeTel: Object } Scratchpad/1:13
"task >" Object { revisionId: "{1429d1d2-58da-4c79-ab6f-7083dc49b46d}", operation: "done" }

Comment 18

[Dietrich Ayala (:dietrich)]

"datastores:" Array [ DataStore ]
"nb friends:" 1
"task >" Object { operation: "clear" }
"task >" Object { operation: "add", id: 1, data: Object }
"data >" Object { byTel: Object, treeTel: Array[0] }
"task >" Object { revisionId: "{049187ef-9c5c-413e-bd0f-a0f74d82e88b}", operation: "done" }
"end of iteration"
"the end !"

Comment 19

[Julien Wajsberg [:julienw]]

Just filed bug 997949 for the notification issue that's happening when this bug happens. Rik, Dietrich, can you confirm that the notification was not disappearing for you when this bug happens? Either clicking or entering a thread?

I guess bug 997949 and this bug have the same root cause but it's difficult to find, especially that I don't reproduce on my phone.

Comment 20

[Julien Wajsberg [:julienw]]

Saw this on Natalia's v1.4 Buri, so requesting 1.4 blocker. When this happens, clicking a notification put the Messages app in a inconsistent state.

Comment 21

[Jason Smith [:jsmith]]

QA Wanted to see if we can reproduce on a Buri on 1.4.

Comment 22

[Julien Wajsberg [:julienw]]

Jason, I _saw_ it on Natalia's buri on v1.4. Like bug 997949 I think this happens when we actually use the phone and keeping awake for some days, so I guess we won't be able to reproduce easily using steps.

Comment 23

[Jason Smith [:jsmith]]

(In reply to Julien Wajsberg [:julienw] from comment #22)
> Jason, I _saw_ it on Natalia's buri on v1.4. Like bug 997949 I think this
> happens when we actually use the phone and keeping awake for some days, so I
> guess we won't be able to reproduce easily using steps.

That's not good enough. You need to actually have reproducible STR to make this actionable.

Comment 24

[Julien Wajsberg [:julienw]]

What I mean is that we should block on it so that we can spend more time on it to make it actionable, because it's a serious bug.

Comment 25

[Preeti Raghunath(:Preeti)]

Julien,

Please help understand user impact of the bug. This reads like an inconsistent, timing issue. Want to be sure of the impact before any decisions are made.

Comment 26

[Pi Wei Cheng [:piwei] (inactive)]

(In reply to Jason Smith [:jsmith] from comment #21)
> QA Wanted to see if we can reproduce on a Buri on 1.4.

Following repro steps at comment 7, issue is NOT reproducible with today's 1.4.
Tapping on an SMS notification correctly takes user to the corresponding message thread. Repro rate: 0 out of 5 attempts.

Device: Buri 1.4 MOZ
BuildID: 20140421000201
Gaia: 3c53bebcc7541e5d19c96cf38ee2603927478f3c
Gecko: 97dfbd4530a0
Version: 30.0a2
Firmware Version: v1.2-device.cfg

Comment 27

[Julien Wajsberg [:julienw]]

(In reply to Preeti Raghunath(:Preeti) from comment #25)
> Julien,
> 
> Please help understand user impact of the bug. This reads like an
> inconsistent, timing issue. Want to be sure of the impact before any
> decisions are made.

From my understanding, when it happens, it will always happen for the same notification again. I don't know if this likely happens after this though, as it didn't happen to me. It happened at least to 3 people though: Dietrich, Natalia, Rik, which is IMO enough to have a blocking decision. 3 people among the few that dogfood and report bug is a lot.

Comment 28

[Anthony Ricaud (:rik)]

Impact of this bug for me:
I received a SMS from person A. It was short enough that I could read all of it in the notification. When I taped it, I started typing directly my answer. I tapped send and actually sent a message to the wrong person because of this bug.

Comment 29

[Preeti Raghunath(:Preeti)]

Julien

DO we have enough info for fixing it given the info. Impact from rik sounds bad, so will be blocking if you have info to fix

Comment 30

[Anthony Ricaud (:rik)]

Why should we have info to fix to mark as blocker? I don't see anything related to "info to fix" on https://wiki.mozilla.org/B2G/Triage. We have three dogfooders, this is a regression in one of the core apps. We should block.

If it's the last blocker and we have no clear STRs, then we will remove the blocker flag and just put something in the release notes.

Comment 31

[Julien Wajsberg [:julienw]]

Exactly the same advice than Rik.

Comment 32

[Preeti Raghunath(:Preeti)]

1.4+ for user impact.

Comment 33

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

Hi David,
As this is set blocking, should we find someone else to handle while Julien is away?

Comment 34

[Julien Wajsberg [:julienw]]

I was requesting blocking but now we don't see this anymore on Natalia's phone or on Rik's phone. So maybe it's been fixed by another patch.

Natalia, can you confirm that you don't see this issue on your current 1.4 build?

Comment 35

[Preeti Raghunath(:Preeti)]

Backlog based on comment #34. Please re-nom if issue is seen again.

Comment 36

[Anthony Ricaud (:rik)]

Also asking Vivien who told me he saw that often on his phone. If he doesn't see it anymore, that's one more sign.

Comment 37

[Natalia Martinez-Winter]

I don't see the issue in my current 1.4 build :
build id : 20140428000206
git commit info : 2014-04-26 20:43:18
d23e479e

Comment 38

[Julien Wajsberg [:julienw]]

Please reopen if you see ths bug happening again.

Comment 39

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

I will reopen the bug if I see it at some point.

Comment 40

[David Scravaglieri [:scravag]]

clear n? per Vivien's comment