Closed Bug 1072738 Opened 7 years ago Closed 7 years ago

[NFC][KK] Could not share URL via NFC when initial flash device


(Firefox OS Graveyard :: NFC, defect)

Gonk (Firefox OS)
Not set


(blocking-b2g:2.1+, b2g-v2.1 verified, b2g-v2.2 verified)

2.1 S6 (10oct)
blocking-b2g 2.1+
Tracking Status
b2g-v2.1 --- verified
b2g-v2.2 --- verified


(Reporter: ashiue, Assigned: allstars.chh)



(Keywords: regression)


(3 files)

Attached file cannot_share_URL.log
Full flash KK build
Gaia-Rev        03d7bcad57ea281869976a9aed0a38849f7c8bc5
Build-ID        20140924160204
Version         35.0a1

1. Flash KK build on two phones
2. Enable NFC on both phones
3. Open website 
4. Tap two phones together 
5. Swept shrinking UI 

Expect result:
Share URL successfully

Actual result:
Could not send URL via NFC unless reboot device
[Blocking Requested - why for this release]:
This is basic function issue
blocking-b2g: --- → 2.1?
QA Whiteboard: [COM=NFC]
Keywords: regression
update [2.1] test version
Gaia-Rev        a7e53d661a1329d6813bc6104555b57dbb5e4d85
Build-ID        20140924160202
Version         34.0a2
I'm getting the same behaviour each time I do make reset-gaia. Resetting the phone helps and fixes this. Maybe this is somehow related to FTU? I've checked that the system browser is listening for peerready events and Gecko actually dispatches the event, but it does not reach the system browser.
With additional Gecko and NfcHandler logging.
This can be compared with attachment 8495891 [details]. It contains the log after restarting the phone, URL share is successful then.
Findings from comparison of the url_share_not_working_after_flash attachment 8495891 [details] (case 1) and url_share_working_after_restart attachment 8495893 [details] (case 2) logs:

1. In both cases NfcHandler is instantiated and listens for peerready event (case 1 log):
>I/GeckoConsole( 3245): Content JS LOG: NfcHandler instantiated 
>I/GeckoConsole( 3245):     at NfcHandler (app://
>I/GeckoConsole( 3245): Content JS LOG: NfcHandler starts to listen for peerready 
>I/GeckoConsole( 3245):     at nh_start (app://

2. In both cases we can see that Gecko code which dispatches peerready event is called (case 1 log):
>I/Gecko   ( 3245): -*- Nfc: Received message from content process: {"target":{},"name":"NFC:NotifyUserAcceptedP2P","sync":false,"json":{"appId":1030},"data":{"appId":1030},"objects":{}}
>I/Gecko   ( 3245): -*- NfcContentHelper: Message received: {"target":{},"name":"NFC:PeerEvent","sync":false,"json":{"event":1,"sessionToken":"{5171c39e-e44a-433e-9c74-3824bf082289}"},"data":{"event":1,"sessionToken":"{5171c39e-e44a-433e-9c74-3824bf082289}"},"objects":{}}
>I/Gecko   ( 3245): -*- Nfc DOM: fire onpeerready sessionToken : {5171c39e-e44a-433e-9c74-3824bf082289}
>I/Gecko   ( 3245): -*- Nfc: Received message from content process: {"target":{},"name":"NFC:CheckSessionToken","sync":true,"json":{"sessionToken":"{5171c39e-e44a-433e-9c74-3824bf082289}"},"data":{"sessionToken":"{5171c39e-e44a-433e-9c74-3824bf082289}"},"objects":{}}
>I/Gecko   ( 3245): -*- Nfc DOM: In MozNFCPeer Constructor
>I/Gecko   ( 3245): -*- Nfc DOM: onpeerready should be sent
This is basically the end of log related to sharing in case 1 (there is also techLost but it's not relevant for us)

3. In case 2 we can see that the event is successfully delivered to NfcHandler and url is shared, gecko log:
>I/Gecko   (  279): -*- Nfc: Received message from content process: {"target":{},"name":"NFC:NotifyUserAcceptedP2P","sync":false,"json":{"appId":1030},"data":{"appId":1030},"objects":{}}
>I/Gecko   (  279): -*- NfcContentHelper: Message received: {"target":{},"name":"NFC:PeerEvent","sync":false,"json":{"event":1,"sessionToken":"{50cef1c1-0ad0-40e4-b87d-498754aaf6b9}"},"data":{"event":1,"sessionToken":"{50cef1c1-0ad0-40e4-b87d-498754aaf6b9}"},"objects":{}}
>I/Gecko   (  279): -*- Nfc DOM: fire onpeerready sessionToken : {50cef1c1-0ad0-40e4-b87d-498754aaf6b9}
>I/Gecko   (  279): -*- Nfc: Received message from content process: {"target":{},"name":"NFC:CheckSessionToken","sync":true,"json":{"sessionToken":"{50cef1c1-0ad0-40e4-b87d-498754aaf6b9}"},"data":{"sessionToken":"{50cef1c1-0ad0-40e4-b87d-498754aaf6b9}"},"objects":{}}
>I/Gecko   (  279): -*- Nfc DOM: In MozNFCPeer Constructor
>I/Gecko   (  279): -*- Nfc DOM: sendNDEF
>I/Gecko   (  279): -*- NfcContentHelper: write ndef
>I/Gecko   (  279): -*- Nfc DOM: onpeerready should be sent
>I/Gecko   (  279): -*- Nfc: Received message from content process: {"target":{},"name":"NFC:WriteNDEF","sync":false,"json":{"requestId":"aWR7YmQ4ZTUzMjktNzZmNi00YTBkLWE2ZDItNjc1NDYyNzM2Y2U0fQ==","sessionToken":"{50cef1c1-0ad0-40e4-b87d-498754aaf6b9}","records":[{"tnf":"well-known","type":{"0":85},"payload":{"0":4,"1":115,"2":117,"3":112,"4":112,"5":111,"6":114,"7":116,"8":46,"9":109,"10":111,"11":122,"12":105,"13":108,"14":108,"15":97,"16":46,"17":111,"18":114,"19":103,"20":47}}]},"data":{"requestId":"aWR7YmQ4ZTUzMjktNzZmNi00YTBkLWE2ZDItNjc1NDYyNzM2Y2U0fQ==","sessionToken":"{50cef1c1-0ad0-40e4-b87d-498754aaf6b9}","records":[{"tnf":"well-known","type":{"0":85},"payload":{"0":4,"1":115,"2":117,"3":112,"4":112,"5":111,"6":114,"7":116,"8":46,"9":109,"10":111,"11":122,"12":105,"13":108,"14":108,"15":97,"16":46,"17":111,"18":114,"19":103,"20":47}}]},"objects":{}}
The corresponding log from NfcHandler is couple lines below:
>I/GeckoConsole(  279): Content JS LOG: NfcHandler got event peerready 
>I/GeckoConsole(  279):     at nh_handleEvent (app://
>I/GeckoConsole(  279): Content JS LOG: NfcHandler we have an url to share 
>I/GeckoConsole(  279):     at nh_handleEvent (app://
>I/GeckoConsole(  279): Content JS LOG: NDEF should be shared 
>I/GeckoConsole(  279):     at nh_sendNDEFMessageToNFCPeer (app://
Hi Yoshi could you take a look at comment 6? I don't understand how is this possible that Gecko dispatches the event but it does not reach NfcHandler and why restarting the phone fixes this. Maybe you have some suggestions?
Flags: needinfo?(allstars.chh)
triage: broken function.
blocking-b2g: 2.1? → 2.1+
Assignee: nobody → allstars.chh
Flags: needinfo?(allstars.chh)
This bug is not occurring for me on the latest build:
Gaia: 5a18267648164b3914735b059018a461ad2a7b71
Gecko: 9ccdefca9784a481fe5781d08c9bb5cf5c338731 (
I haven't finished yet, but so far the problem is from BrowserDB.init(callback) in browser/js/browser.js.

The callback seems to be executed on b2g process, and this callback will override the eventTarget which is registered by nfc_*.js in System app.

So the onpeerready is actually notified to the mozNfc object in browser/js/browser.js.
And the reason why latest master can work is the browser.js is just removed in Bug 1043959.

Although latest m-c fixes this however I still need to check this for 2.1 branch.
Make this depends on Bug 1043959, since if Browser app is removed then this problem should be gone.
Hi Ben
Do you know Browser app will still be launched in FTU?
Although Browser app is already removed in Bug 1043959, however it hasn't been uplifted to v2.1 branch yes so Aurora branch still has this problem.

And it happens only in the first time, after adb reboot the Browser app won't be launched.
Also launch FTU from Settings->Developer won't have this problem either.

I'd like to make sure that we didn't miss any potiential problem here.

Below is the b2g-ps result after I did 'make reset-gaia'

 adb shell b2g-ps
b2g              0 root      5632  1     216216 114424 ffffffff b6e6c894 S /system/b2g/b2g
b2g              0 root      5636  5632  56684  5640  ffffffff b6e6ca60 S /system/b2g/b2g
OperatorVariant  2 u0_a5800  5800  5632  97192  49076 ffffffff b6f37894 S /system/b2g/plugin-container
Browser          2 u0_a5826  5826  5632  96084  47872 ffffffff b6ea6894 S /system/b2g/plugin-container
Built-in Keyboa  2 u0_a5945  5945  5632  106712 51028 ffffffff b6e70894 S /system/b2g/plugin-container
Homescreen       2 u0_a5986  5986  5632  110352 59348 ffffffff b6e80894 S /system/b2g/plugin-container

Thank you.
Flags: needinfo?(bfrancis)
Also I found that the Browser app will be launched if SIM is inserted.
Oh the Browser is launched because of first-run-with-sim system message.
Flags: needinfo?(bfrancis)
Make this as duplicated as Bug 1043959 as the problem is Browser app overrides the event registration done by System app, since Bug 1043959 is to remove Browser app so the problem should be also fixed.
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1043959
Alison, can you retest to see if this bug is still valid now that bug 1043959 has been fixed and uplifted to 2.1?
Flags: needinfo?(ashiue)
Keywords: verifyme
Verified on
Gaia-Rev        778ebac47554e1c4b7e9a952d73e850f58123914
Build-ID        20141006000205
Version         34.0a2

Gaia-Rev        470826d13ae130a5c3d572d1029e595105485fb0
Build-ID        20141006040204
Version         35.0a1
Flags: needinfo?(ashiue)
Target Milestone: --- → 2.1 S6 (10oct)
This issue is verified fixed on Flame KK 2.2 and 2.1

Flame 2.2

Environmental Variables:
Device: Flame 2.2 Master (319MB)
BuildID: 20141011040204 (Full Flash)
Gaia: 95f580a1522ffd0f09302372b78200dab9b6f322
Gecko: 3f6a51950eb5
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Flame 2.1

Environmental Variables:
Device: Flame 2.1 (319MB)
BuildID: 20141011000201 (Full Flash)
Gaia: f5d4ff60ffed8961f7d0380ada9d0facfdfd56b1
Gecko: d813d79d3eae
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

The URL is shared successfully over NFC.
QA Whiteboard: [COM=NFC] → [COM=NFC] [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: verifyme
To clarify, I have tested this immediately after initially full flashing the devices.  The URL was transferred successfully via NFC.
QA Whiteboard: [COM=NFC] [QAnalyst-Triage?] → [COM=NFC] [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
You need to log in before you can comment on or make changes to this bug.