Closed Bug 1072738 Opened 10 years ago Closed 10 years ago

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

Categories

(Firefox OS Graveyard :: NFC, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

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

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

People

(Reporter: ashiue, Assigned: allstars.chh)

References

Details

(Keywords: regression)

Attachments

(3 files)

Attached file cannot_share_URL.log
Full flash KK build Gaia-Rev 03d7bcad57ea281869976a9aed0a38849f7c8bc5 Gecko-Rev https://hg.mozilla.org/mozilla-central/rev/1735ff2bb23e Build-ID 20140924160204 Version 35.0a1 STR: 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 Gecko-Rev https://hg.mozilla.org/releases/mozilla-aurora/rev/84d2b47c102d 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://system.gaiamobile.org/js/nfc_handler.js:5:4) >I/GeckoConsole( 3245): Content JS LOG: NfcHandler starts to listen for peerready >I/GeckoConsole( 3245): at nh_start (app://system.gaiamobile.org/js/nfc_handler.js:12:8) 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://system.gaiamobile.org/js/nfc_handler.js:25:6) >I/GeckoConsole( 279): Content JS LOG: NfcHandler we have an url to share >I/GeckoConsole( 279): at nh_handleEvent (app://system.gaiamobile.org/js/nfc_handler.js:33:8) >I/GeckoConsole( 279): Content JS LOG: NDEF should be shared >I/GeckoConsole( 279): at nh_sendNDEFMessageToNFCPeer (app://system.gaiamobile.org/js/nfc_handler.js:55:8)
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 (https://github.com/mozilla/gecko-dev/commit/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 APPLICATION SEC USER PID PPID VSIZE RSS WCHAN PC NAME 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.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
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 [2.1] Gaia-Rev 778ebac47554e1c4b7e9a952d73e850f58123914 Gecko-Rev https://hg.mozilla.org/releases/mozilla-aurora/rev/c4a4b04c617c Build-ID 20141006000205 Version 34.0a2 [2.2] Gaia-Rev 470826d13ae130a5c3d572d1029e595105485fb0 Gecko-Rev https://hg.mozilla.org/mozilla-central/rev/e0d714f43edc Build-ID 20141006040204 Version 35.0a1
Status: RESOLVED → VERIFIED
Flags: needinfo?(ashiue)
Resolution: DUPLICATE → FIXED
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.

Attachment

General

Creator:
Created:
Updated:
Size: