Build ID 20150419162502 Gaia Revision c15a2b6d3a783813959c2b3bffd2a131f4270b9e Gaia Date 2015-04-17 17:49:32 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/cc02ee38b252 Gecko Version 37.0 Device Name hammerhead Firmware(Release) 5.1 Firmware(Incremental) eng.cltbld.20150419.201551 Firmware Date Sun Apr 19 20:16:07 EDT 2015 Bootloader HHZ12f STR: 1. Enable NFC on both phones 2. Device A launch contact app and open a specific contact 3. Device A click home button back to home screen 4. Device A launch Dialer app 5. Tap two phones together, and check device A Expected result: Device A would not show shrinking UI Actual result: Device A show shrinking UI and after swipe shrinking UI, device B would receive the contact which running at background. Please refer: http://youtu.be/dC6xh5DwsG8

I found that actually Dialer and Contacts are running on the same process (b2g-ps : show Communucations) And these two apps also have the same manifestURL and same appId (got from AppService) , so Gecko and NfcManager in nfc_manager.js cannot tell from them. I don't know when or why there two apps are merged into same process, maybe need comments from Gaia side.

ni? for Vincent and Wesley for this, This change (Dialer and Contacts running on the same process) is already landed in v2.2 and NFC (Gecko + Gaia) cannot tell from them because their appId/manifestURL are the same. Whether how we will fix this may require some huge change in v2.2.

Is it possible that we can identify dialer apps is running and contact is in the foreground?

Hi George In nfc_manager.js, it uses manifestURL when calling checkP2PRegistration() https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/nfc_manager.js#L282 But in this case, Contacts and Dialer both have the same manifestURL, so Gecko cannot tell from them. Is there other attribute from TopMostWindow you can disinguish these two apps?

triage: really bad experience. however it's too risky to have such big fix in 2.2, let's block 2.0 then.

I think we can use name attribute. ex: activeApp.name === 'Contacts' || 'Phone'.

The Dialer and Contacts apps each have different entry points in the Communications manifest.

Hi Garner, can you help this bug? Thanks.

If I understand the problem correctly, there is only one NFC navigator object in the app: window.navigator.mozNfc. The app ought to have enough information to know what to send or allow based on its own internal state, and route the correct data accordingly whenever the app view changes. Here, the dialer of "communications app" is in front, not contacts of "communications app". The communications app will need a mini "NFC manager" of sorts inside the app based on which iframe or view is visible to the user. onpeerready (onpeerfound is also available) is used, so maybe the correct change is for the comms app to simply unset the callback until the "active" view is present again, or send some other data (the phone number). (BTW, the MDN docs seem to be only halfway updated with regards to onpeerready versus onpeerfound usage).

Just a suggestion (I am just looking at the contact details code). Something like this *might* work without modifying any other code: contacts/js/views/details.js: ... document.addEventListener("visibilitychange", onchange); ... function onchange(event) { // if hidden or lost focus: contacts.NFC.stopListening(); }

This requires changes from Dialer app and Contacts app to use onpeerfound NFC API introduced in v2.2, and launching ShrinkingUI when onpeerfound calls, as Gallery app already did this in Bug 1163957. ni? for Wesley as this requires lotssssssss help from Comms team.

Hi Francisco, This is a carry-over blocker involving both dialer and contact.

There is not much we can do, unless we separate finally contacts and dialer into separate apps. During this week we will put over the table if we take this action or not.

[Tracking Requested - why for this release]: Removing from 2.5 and putting in backlog

Firefox OS is not being worked on