Description: If the user is composing a new SMS, taps on the "+" to add a contact to the "To:" field, it will view the contact's information instead of adding them as a recipient if the "Contacts" app is open in the background. Repro Steps: 1) Updated Buri to Build ID: 20131009004001 2) Tap on the "Contacts" icon to open contacts. 3) Tap the "Home Button" on the phone to return to the homescreen. 4) Tap on the "SMS" icon to open messaging. 5) Tap on the "Compose New Message" icon. 6) Tap on the "+" icon and tap on a contact name to add them as a recipient. 7) Tap on the "+" icon again and tap on another contact name. Actual: The user will be view the contact's information instead of adding them to the "To:" field. Expected: The contact selected will be added as a recipient to the "To:" field. Environmental Variables Device: Buri v 1.2.0 Mozilla RIL Build ID: 20131009004001 Gecko: http://hg.mozilla.org/releases/mozilla-aurora/rev/e5edb484e2a9 Gaia: 672c47bf94b69a329e0aacb9228a6aa16ade6226 Platform Version: 26.0a2 RIL Version: 01.02.00.019.056 Notes: Repro frequency: 100% See attached: logcat

This issue does not occur on Leo v1.1 Mozilla Rill Environmental Variables Device: Leo v 1.1.0 Mozilla COM RIL Build ID: 20131001041206 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/c630289d6388 Gaia: 02b975e6ce12922928c74276ac7d19432a03f126 Platform Version: 18.1 RIL Version: 01.01.00.019.240 The contact is added to the "To:" field and not taken to the view the contact's information.

(In reply to ktucker from comment #0) > Created attachment 814951 [details] > logcat > > Description: > If the user is composing a new SMS, taps on the "+" to add a contact to the > "To:" field, it will view the contact's information instead of adding them > as a recipient if the "Contacts" app is open in the background. > > Repro Steps: > 1) Updated Buri to Build ID: 20131009004001 > 2) Tap on the "Contacts" icon to open contacts. > 3) Tap the "Home Button" on the phone to return to the homescreen. > 4) Tap on the "SMS" icon to open messaging. > 5) Tap on the "Compose New Message" icon. > 6) Tap on the "+" icon and tap on a contact name to add them as a recipient. > 7) Tap on the "+" icon again and tap on another contact name. > > Actual: > The user will be view the contact's information instead of adding them to > the "To:" field. > > Expected: > The contact selected will be added as a recipient to the "To:" field. Confirmed. This is actually controlled by the Contacts app: updating component.

Seems to be a similar problem than bug 924694

View contact on 2nd SMS recipient first occurs on the 10/8 1.3 build. - Issue doesn't appear on Buri 1.3 Moz 10/5 - Gaia c9090021f7d642bae1db73a1093ab3dbb5078642 SourceStamp b5d24ef1eb37 BuildID 20131005040201 Version 27.0a1 Builds 10/6 and 10/7 are untestable and stuck in a boot loop. - Issue first starts appearing on Buri 1.3 Moz 10/8 - Gaia 122ff8c6363227501f4121e5a3892ba41d4c0417 SourceStamp 64b497e6f593 BuildID 20131008064334 Version 27.0a1

Pretty bad user experience and hence bumping it to koi+

Hi all, I'll need some help from @fabrice here. The second time that we launch the activity (following the steps to verify) we have this error: E/GeckoConsole( 892): [JavaScript Error: "NS_NOINTERFACE: Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsISupports.QueryInterface]" {file: "jar:file:///system/b2g/omni.ja!/components/ActivityWrapper.js" line: 47}] I was debugging and saw in the second call how we were setting up the handler: https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/contacts/js/contacts.js#L739-L741 but whenver we really setup the handler: |window.navigator.mozSetMessageHandler('activity', actHandler); | We got the error above: [nsISupports.QueryInterface]" {file: "jar:file:///system/b2g/omni.ja!/components/ActivityWrapper.js" line: 47}] Ending up in not executing the |actHandler| function, in this case |ActivityHandler.handle| who is in charge of making the clicks that we do behave in a different way depending if we are handling an activity or not. So, seems to me that we will need some of the magic help from Fabrice here. Thanks! F.

Francisco, I don't see any big change on the gaia side around this code lately, so I'm going to bisect gecko. Stop me if I'm wrong ;)

From the logs, after we complete the first activity we get an "inner-window-destroyed" notification. That usually means that the page serving the activity was closed or navigated to another url. Is that the case here?

So, I have good news and bad news... The good news is that I isolated the gecko regression. The bad news (especially for ferjm), is that it's bug 915598 again (I also had to backout 927363 to get a build that worked. Fernando, the fact that we get an inner-window-destroyed with 915598 makes me think that we may not use the right kind of message listener, but I didn't test a change yet. If we can't fix that fast, we'll have to backout I'm afraid.

1- This patch fixes the issue (at least on my local tests). 2- We need a bigger "+" button or smaller fingers :\

And now without whites paces... Sorry for the spam

Backed out for M-oth failure. https://tbpl.mozilla.org/php/getParsedLog.php?id=29275912&tree=Mozilla-Inbound https://hg.mozilla.org/integration/mozilla-inbound/rev/cd77d501b40c

Green on try https://tbpl.mozilla.org/?tree=Try&rev=9c7bc7218d93 https://hg.mozilla.org/integration/mozilla-inbound/rev/4e3059e1d9f9

I think we'll switch to an inline activity instead of a window activity for the "send sms" activity. Do you think this will fix/break something here ?