As a user, I want to be able to make use of NFC URL sharing in the System Browser as I was previously able to do in the 2.0 Browser so that I do not lose functionality. Acceptance Criteria: 1. NFC URL sharing in System Browser matches experience in 2.0 Browser.

Saminath, are you able to help with this bug since you did the original Browser implementation?

Garner, do you know if the shrinking UI needs to be ported from the old Browser into the System Browser?

(In reply to Peter Dolanjski [:pdol] from comment #2) > Garner, do you know if the shrinking UI needs to be ported from the old > Browser into the System Browser? ShrinkingUI is still a system "dialog", and not yet a separate application only UI, so much of this should be hidden from the webapp currently. I haven't actually verified it works yet. The system browser when it is used would require NFC privilages to be added if not already at least so it can access the NFC DOM. There was a separate thread on a more lmited audience NFC mailing list on whether there is any distinction between browserWindow and the appWindow. If they have the same ability to handle events, can receive an "onpeerready" event, and have an ability for the NFC Manager to send that event right back to the same parent gecko process, then the webapp content should still handle the event callback.

I had some idea and we need to experiment. George, please take this one. The following are from my post in fxos-nfc channel: """ Hi all, The bug is not filed yet, but in coming v2.1 we are removing the browser app and use system browser to replace it. So that means the NFC share inside browser app needs to be done in system app. I know we have a plan to make app itself do its own nfc pairing UI, but its ETA is still unknown and we need to make sure the web page pairing feature is not broken. AFAIK, the new process will be: 1. tech-found event in nfc-manager. 2. Start event sent to shrinkUI. 3. ShrinkUI checks if the current app window is a browserWindow or a AppWindow. (by checking its manifestURL). 3a. if it’s an appWindow, tell nfc-manager to send nfc event to the app. 3b. if it’s a browserWindow, call mozNFC.sendmessage inside system app with the browserWindow’s url. I don’t know if 3b. works. Does mozNFC send message needs to be done in the onpeerfound event handler anyway? If not, could we send the manifestURL of system app to gecko to tell it to send onpeerfound to system app? ""

When passing apps://system.gaiamobile.org/manifest.webapp to checkP2PRegistration function may get unexpected result. I'm still investigating on it.

Comment on attachment 8469096 [details] PR to master Hi Alive, could you help to check this patch and let me know your concern? Thanks.

Comment on attachment 8469096 [details] PR to master Please make another nfc_handler.js to deal with onpeerready event. And new it in AppWindowManager. var AppWindowManager = { init: function() { new NfcHandler(this); } } var NfcHandler = function (appWindowManager) { this.appWindowManager = appWindowManager; }

Comment on attachment 8469096 [details] PR to master Hi Alive, I move the logic to nfc_handler.js and add tests. Could you check again? Thanks.

tbpl test result seems good except some known issues, https://tbpl.mozilla.org/?rev=60738b1ff3288a30a2aeda930f4fd08ec763a079&tree=Gaia-Try Thanks Alive, merge to master: https://github.com/mozilla-b2g/gaia/commit/d688d4fb68fe76cfe9fe2bd732e908e073b3b259

Verified on Gaia-Rev 477a9e61c3edf12f32a62a19d329cd277202cc6b Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/67573e422a0f Build-ID 20141015161201 Version 34.0