Every time I go from a thread to the list of the threads, I see contact names, then a flash of the raw phone number and then the contact names come back. It feels really sluggish. Vivien is seeing that too. We think it might be related to Drafts but we haven't checked that. Adding qawanted to see if we can find more reliable STRs

I am having trouble reproducing this bug, can you provide some more info please? What device/version/build# are you using? How many contacts/texts are stored on the device? Are there multiple lengthy threads or just a few short threads, etc. If possible, a video of the issue occurring would be helpful.

I used the debugger to get a stack when this appears: thlui_setContact@app://sms.gaiamobile.org/gaia_build_defer_index.js:415:2102 thlui_appendThread@app://sms.gaiamobile.org/gaia_build_defer_index.js:448:36 thlui_updateThread@app://sms.gaiamobile.org/gaia_build_defer_index.js:447:1 thlui_renderDrafts/</<@app://sms.gaiamobile.org/gaia_build_defer_index.js:432:432 exports.Drafts.forEach/<@app://sms.gaiamobile.org/gaia_build_defer_index.js:301:94 exports.Drafts.forEach@app://sms.gaiamobile.org/gaia_build_defer_index.js:301:1 thlui_renderDrafts/<@app://sms.gaiamobile.org/gaia_build_defer_index.js:432:321 handler@app://sms.gaiamobile.org/gaia_build_defer_index.js:301:481 exports.Drafts.request/<@app://sms.gaiamobile.org/gaia_build_defer_index.js:302:36 As suspected, it is because of threads.

Reading the code, I suspect this happens because Anthony has some leftover drafts from a previous version. This should not happen in current versions. I'm still not sure of this though, I'd like to investigate directly with Anthony. This also happens because our updateThread method is quite dumb: it (nearly) always removes the previous thread and adds a new one. We could try to update the thread without removing it, and only if necessary. This is not _that_ easy because a lot of parameters make a thread.

Repro Steps: 1) Updated Buri to BuildID: 20140415000202 2) 3) 4) Environmental Variables: Device: Buri v1.4 MOZ ril BuildID: 20140415000202 Gaia: c8f916c8569f6ee652237fd10ac925e08cd3d9bc Gecko: f14047fa8d63 Version: 30.0a2 RIL Version: Firmware Version: v1.2-device.cfg Notes: Repro frequency: 100% See attached: Video

(Disregard previous post, hit save by mistake. Apologies.) I am unable to reproduce this issue following the initially described method on the Buri v1.4 MOZ ril, however I do see what I believe is the issue when the sms app is launched for the first time. I am unsure if this is the correct issue being described in the initial post? Some more information as requested in comment 1 would help to clarify. Repro Steps: Prerequisites- Have multiple sms thread histories with numerous saved contacts in the sms app already. 1) Updated Buri to BuildID: 20140415000202 2) Tap on the sms icon 3) Observe the threads display with raw phone numbers momentarily before changing to the names of saved contacts instead 4) Force close sms app and repeat steps 2-3 to see issue again The user sees a flash of raw phone numbers being displayed as the contact names in thread histories momentarily before the numbers change to the correct user names. Contact names appear appropriately in the thread list after the initial launch and when tapping back from an individual thread. Environmental Variables: Device: Buri v1.4 MOZ ril BuildID: 20140415000202 Gaia: c8f916c8569f6ee652237fd10ac925e08cd3d9bc Gecko: f14047fa8d63 Version: 30.0a2 Firmware Version: v1.2-device.cfg Repro frequency: 100% See attached: Video

Is the issue seen in comment 8 happening on 1.3?

Comment 8 is the way we load threads since v1.0. This is not the issue from comment 0 as Anthony showed me in real life.

Wasn't sure if you still needed this, but just in case.. The issue mentioned in comment 8 also occurs on the Buri v1.3 MOZ ril. Environmental Variables: Device: Buri v1.3 MOZ ril BuildID: 20140416004000 Gaia: 11d027ec28d8e8f09c76b35661222499e124abc8 Gecko: ab227cdd984c Version: 28.0 Firmware Version: v1.2-device.cfg Contact names are updated much more quickly than on the Buri v1.4 MOZ ril, but the issue does still occur, along with the issue described in bug 907740.

Maybe the Facebook datastore makes 1.4 slower in that regard, thanks Rachel !

I think this will be fixed by my patch in bug 881469.

Rik, can you comment whether this is fixed on master now?

Since Geeksphone is not providing new nightlies, I'm living on an old master. So keeping the needinfo until I update to a newer master or dogfood on another device.

Gonna mark this as fixed by bug 881469, please reopen if you still see it.

Finally updated and I can't reproduce. Good work! http://ricaud.me/images/success-2.gif

Also, note that we can do a v1.4 specific patch if needed.