Closed Bug 952524 Opened 11 years ago Closed 11 years ago

Opening a new sms from notification shows the wrong message thread

Categories

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

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: zcampbell, Unassigned)

Details

(Keywords: regression)

STR: 1. Save two contacts into the testing phone for which you have second phone/SIMs for 2. Send a message from contact 1 to the phone under test 3. Open SMS app and look at the message thread view from contact 1 4. Send a new message from contact 2 to the phone under test 5. Open the utility tray and tap on the incomin messages from contact 2 Actual: Messages app opens with the header of contact 2 and the message thread of contact 1 Expected: Header of contact 2 and message thread of contact 2. Final step: Tap back, the expected messages thread will then load. Gaia 574f79512a7b8a9ab99211b16a857ab812d7994e Gecko http://hg.mozilla.org/mozilla-central/rev/599100c4ebfe BuildID 20131220040201 Version 29.0a1 I do not have a regression range for this but I know this is several weeks old at least as I found it with my dogfooding phone which has been up for over 12 days.
QAwanted: I'd like to know if this happens on 1.2 and 1.3. (I just reproduced on 1.4 so I don't need this from you). This is a regression because this used to work of course.
blocking-b2g: --- → 1.3?
QA Contact: ckreinbring
Unable to repro on Buri 1.2 and 1.3 mozilla RILs. After tapping the second contact's SMS notification, the message thread appears with the second contact's header info and their SMS message. 1.3 Build ID: 20140103004001 Gecko: http://hg.mozilla.org/releases/mozilla-aurora/rev/d9226a660d52 Gaia: ae7d05689b6b9ac4ec6182217dfdef06be28e886 Platform Version: 28.0a2 1.2 Build ID: 20140103004001 Gecko: http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/9cbbf14a0f69 Gaia: 2b116456d8a3ed3e9741b370d628f225c58587da Platform Version: 26.0
blocking-b2g: 1.3? → 1.4?
Keywords: qawanted
Repros on the Dec 10 build. As far as I know, we don't have access to any earlier 1.4 or 1.4-like builds. Build ID: 20131210040206 Gecko: http://hg.mozilla.org/mozilla-central/rev/df82be9d89a5 Gaia: c952e2756c03eceb4de6a3eba15651741a62f9e8 Platform Version: 29.0a1
Re-reading comment 2 - the build IDs look old. Can we recheck this on the latest 1.3 & 1.2 builds?
Keywords: qawanted
(In reply to Jason Smith [:jsmith] from comment #4) > Re-reading comment 2 - the build IDs look old. Can we recheck this on the > latest 1.3 & 1.2 builds? Oh wait disregard - forgot that has 2014 included in them.
Keywords: qawanted
Does this reproduce on the last 1.3 build (12/9/2013)?
Keywords: qawanted
This issue does reproduce on the 12/9/13 1.3 build. Also, I have found a regression window for this issue showing that it started reproducing on the 12/4/13 1.3 build. - Works - Environmental Variables: Device: Buri v1.3 MOZ RIL BuildID: 20131203040236 Gaia: 31808a29cfcffa584b6a88b4f1e515387f485a1b Gecko: 8648aa476eef Version: 28.0a1 Firmware Version: V1.2_US_20131115 - Broken - Environmental Variables: Device: Buri v1.3 MOZ RIL BuildID: 20131204115608 Gaia: 324c467fc6b202fd09efe4b16cd83960fd2901eb Gecko: 526e12792fc8 Version: 28.0a1 Firmware Version: V1.2_US_20131115
Keywords: qawanted
QA Contact: ckreinbring → mvaughan
blocking-b2g: 1.4? → 1.3?
Why a 1.3 flag if it works on the current 1.3 build (see comment 2) ?
Comms team tested it working on a January build. It's working fine. QAWANTED to confirm on the latest build. Thanks
(In reply to Julien Wajsberg [:julienw] from comment #8) > Why a 1.3 flag if it works on the current 1.3 build (see comment 2) ? Probably cause I read the bug too quickly. The regression window points to the fact that this would be part of 1.3, as the window indicates this regressed on 12/3/2013. QA Wanted anyways to see if this reproduces on 1.4.
blocking-b2g: 1.3? → 1.4?
Keywords: qawanted
(In reply to Jason Smith [:jsmith] from comment #10) > (In reply to Julien Wajsberg [:julienw] from comment #8) > > Why a 1.3 flag if it works on the current 1.3 build (see comment 2) ? > > Probably cause I read the bug too quickly. The regression window points to > the fact that this would be part of 1.3, as the window indicates this > regressed on 12/3/2013. > > QA Wanted anyways to see if this reproduces on 1.4. And double check the behavior on 1.3.
(In reply to Jason Smith [:jsmith] from comment #10) > QA Wanted anyways to see if this reproduces on 1.4. This issue reproduces on the 01/08/14 Master (1.4) build. Environmental Variables: Device: Buri Master (1.4) MOZ RIL BuildID: 20140108040200 Gaia: b7a7191f761933fd4878227488c75d09f5ba890c Gecko: cf2d1bd796ea Version: 29.0a1 Firmware Version: V1.2_US_20131115 (In reply to Jason Smith [:jsmith] from comment #11) > And double check the behavior on 1.3. This issue does not reproduce on the 01/08/14 1.3 build. Environmental Variables: Device: Buri v1.3 MOZ RIL BuildID: 20140108004001 Gaia: 522779225e86b7a4d1bf759036678dc321a1486e Gecko: 2287f2839256 Version: 28.0a2 Firmware Version: V1.2_US_20131115
Keywords: qawanted
The gaia range from comment 7 does not yield anything useful. I don't see much from the Gecko range either but I'm less used to it. Will need someone to investigate. Borja, can you have a look ?
Flags: needinfo?(borja.bugzilla)
After testing it's WORKSFORME BUILD 12/02/2014 Gecko: dcea739 Gaia: f1b81b0 STR is working as expected.
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: needinfo?(borja.bugzilla)
Resolution: --- → FIXED
Resolution: FIXED → WORKSFORME
No longer blocks: fxos-papercuts
blocking-b2g: 1.4? → ---
You need to log in before you can comment on or make changes to this bug.