Currently when one initiates a conversation on one device and the receiver sends a message back, the conversation initiated and in focus on B2G will not update the visible conversation to display new messages. The notification in the status bar up top indicates a newly received message but the conversation does not reflect and display the newly inbound message. Steps to Reproduce i) Send a text message to a contact from B2G to any other device. Keep the conversation in view and in focus. ii) Reply back to the B2G device and see the notification denote the new message ER: Conversation updated on the B2G device AR: Conversation not updated despite having a newly inbound message Work-around to update the conversation is to tap the notification. See screenshot where I have a new notification with a new message from the same contact but the conversation is not updated. -- Unagi (10/30)

Works for me on otoro 10/31. Gecko-b1485a1 Gaia-6e5b722

This seems fixed with the 10/31 build. Do we know which change-set fixed this?

Nov 1 build. gecko-aurora: 46a6feeaf9c5 gaia: 2b1ee6f8389212c46634959a3922288c286bbfc4 Still not working

(In reply to dscravaglieri from comment #3) > Nov 1 build. > > gecko-aurora: 46a6feeaf9c5 > gaia: 2b1ee6f8389212c46634959a3922288c286bbfc4 > > Still not working I just flashed 11/01, and this is working for me.

still can reproduce build info gaia master : 0de95077576a7e11034e8cdd0672eba613384003 mozilla-aurora(hg) : 8ae22fe748fc

This bug is related with PhoneNumberJS bug (https://bugzilla.mozilla.org/show_bug.cgi?id=808815) and the patch is available here https://github.com/mozilla-b2g/gaia/pull/6273

Milestoning for C2 (deadline of 12/10), as this meets the criteria of "remaining P1 bugs not already milestoned for C1".

Was fixed with https://bugzilla.mozilla.org/show_bug.cgi?id=806592

Reopening, as I still see this testing with unagi using: gaia: 620399e19efe849b9dddeffe7e11003847f6b268 gecko: f423bd0551fcf872eb58064ed72ed2a4aed2c2d2 I only this bug when I am sending from my unagi device to another phone, not the other way around, so my STR are the same as Aaron's in the initial comment. This was tested using two different networks, both AT&T and TMobile.

[:marcia] I've tested with two Unagi with two Spanish SIM Cards (Orange & Movistar) and it's working for me. I would need more info in order to check what is happening. - Have you pressed 'reset-phone' before the test? - Without saving these numbers in contacts, could you tell me which 'country-code' is added when you see 'Thread-list' in your Unagi? - Please try the following scenario: ---> 'make reset-gaia' to both Unagi ---> Make a call between them, Is it working? ---> If the call was made properly, send a SMS from Unagi A to Unagi B, is the country code set properly in both cases? Thanks!

I tested this a number of times, between t-mobile, at&t and google voice. I got it to happen *once*. However, the rest of the time I could not reproduce.

Confirming that this is broken again (Unagi 11/21).

Check the process of this bug... https://bugzilla.mozilla.org/show_bug.cgi?id=812930

This bug isnt related to the other 2, if you hit the other 2 you would not be able to see the main thread listing

Only for clarifying. SMS App has no changes since one week and a half ago, so Im really worried about all the issues coming and being reopened. Are we having some modifications in Gecko? Why one day everything works properly, and day after everything it's broken? :S For me it's working properly, 11/22 Build, Otoro, Latest Gaia. Please recheck again.

Why is this resolved again?

Sorry I accidentally opened this, @aaronmt David said he has tested this and it worked, if you are still having problems then reopen. And I just want to bring up that just because a limited amount of local testing is working and there havent been any code changes doesnt mean there is not a bug. People are using these phones with real world usage patterns and having their data go through various upgrades, if our tests are passing but someone sees a bug, we have to look into what we arent testing

Tested on a Unagi Device, Build Id: 20130205070201 Git Commit Info : 2013-01-31 16:59:41 , c4589884c89f724ba0f72107968d4111... (did an update over the air) I had this issue reoccuring in this latest build, however this happened only for the first time when I try to initiate a conversation, either with the unagi device to another phone or from another phone to the unagi device... When I tap on the notification, or when I tap on Back ('<') and then come back to the same message thread, I see the new message. From then on, all the new incoming messages are populated corretly on the thread, irrespective of the notification status.

I'm dog fooding a Keon and a Peak--both running v1.2 stable images from geeksphone--and while having a text message conversation with a friend, the conversation view consistently fails to auto-scroll when new messages are received and when I send new replies. I'm constantly having to flick up to get it to scroll down and show the latest messages in the conversation. This may have been fixed in v1.3 or master. The repro is this: 1. Do multiple send and receives to build up a conversation that is larger than what can fit on the screen. 2. Tap on the conversation view so that the message input box loses focus. You may need to hit the home button to go to the home screen and/or kill the app and relaunch it. 3. Send a new message and see that the conversation view doesn't auto-scroll to show it. 4. Flick up to scroll and show the latest message. 5. Receive a reply and see that the conversation view again doesn't auto-scroll to show it.

Hey, please file a new bug, thanks! I can still give a little more context: * starting with 1.2, when the view is scrolled up we don't scroll down when we receive a message. However this should still automatically scroll down when you receive a message if the thread view is scrolled down to the bottom. * in 1.3 we implemented bug 905208 which gives a more consistent behavior and feedback * 1.3 has currently another related issue that we'll definitely fix: bug 947977