963541, 964194, 991970, 996397, 1003268, 1007724, 1046554, 1047233, 1048676, 1052309, 1053732, 1054139, 1055560, 1073421, 1074611, 1082300, 1082440, 1082443, 1082445, 1082475, 1085292, 1086179, 1087853, 1087925, 1090803, 1091356, 1094147, 1094148, 1109458, 1117633, 1120315, 1126653, 1127726, 1129841, 1131454, 1131964, 1133390
Current NFC APIs, as represented by MozNFCTag and MozNFCPeer are certified only by permission settings. Improving NFC APIs and investigating how to open them up to more than certitified app permissions will be necessary, as the complimentary Secure Element APIs (Bug 879861) will also be targeted at privilaged level permissions eventually.
noming for 2.2
feature-b2g: --- → 2.2?
Summary: (meta) [NFC] Make NFC APIs available to privilaged webapps instead of certified only. → (meta) [NFC] Make NFC APIs available to privileged webapps instead of certified only.
Summary: (meta) [NFC] Make NFC APIs available to privileged webapps instead of certified only. → (meta) [NFC] Make NFC APIs available to privileged webapps
According to Comment 0, the purpose is to let privilege app to use NFC API. Remove dependencies as most bugs are not related to this.
(In reply to Yoshi Huang[:allstars.chh] from comment #2) > According to Comment 0, the purpose is to let privilege app to use NFC API. > Remove dependencies as most bugs are not related to this. Given now there's no User Story defined how to read a tag, operate on a tag, or using other NFC Technology to operator on it, or how foreground app should acquire the tag, and also using custom P2P Sharing UI is not defined yet (Can custom Sharing UI override HOME key? Does it need to vibrate?) There are many things unclear yet, so I also removed the dependencies here.
Hi Yoshi, I have updated the user story to indicate priority 1 and priority 2 use cases. Can you help list any open items for each? The priority 2 items could go its own separate bug if needed, and we can use this bug for priority 1 items.
Hi Sandip This is a meta bug for engineering bugs, please file a seperate bug for User Story. Also the meta bug for NFC user story is Bug 933150.
Summary: (meta) [NFC] Make NFC APIs available to privileged webapps → (meta) [NFC] Make NFC Peer APIs available to privileged webapps
[NI to Jonas and Tim as head up] Hope the communication isn't too late. We are about to make these NFC p2p sharing APIs privileged in 2.2. But within 2.2 timeframe it's less likely to move shrinking UI out of system app clearly. The current plan is to approach the final goal step by step.
I basically agree with Jonas on our previous conclusion that we should aim to expose a proper API and solid app-launch flow than expose and change it later. But obviously you have some other concerns. Jonas can help you on how to migrate it.
Like I've said since before the current API landed: We need to move the UX from the API and into apps themselves. The current API is not a generic NFC API, it's a NFC sharing API, no other use cases are currently possible. If we want to support sharing through NFC exposed to third party apps, it's better that we do that through WebActivities.
(In reply to Jonas Sicking (:sicking) from comment #8) > If we want to support sharing through NFC exposed to third party apps, it's > better that we do that through WebActivities. I think what Jonas meant is we need to implement a MozActivity which implements share through 'nfc', see some comments from Bug 963531. And this MozActivity could be from System app or a 3rd party app if user wants a different sharing exprience. If this is what we are going to do, then make Share API privilege should be landed *after* shared by Activity is done.
Writing the sharing activity will also help to validate NFC sharing API as a whole before exposing it. I assume we could introduce an 'nfc-share' activity handler (nfcManager seems a good place), which will: 1. Validate the payload. 2. Start to listen for onpeerfound. 3. Show visual info requesting the user to put the phone against nfc peer, show cancel share button. 4. Send the payload once nfc peer is detected. Update UI to show status of sending. 5. Stop listening for onpeerfound and close activity handler.
Is the Activity going to be the only way for non-certified apps to do peer-to-peer interactions with NFC? Or can privileged apps use the API directly instead of having the experience mediated via the Activity?
I think we can use sendNDEF/sendFile/onpeerready in privileged application after this bug is fixed.
Since Jonas suggests not to open NFC Share API, I'll update the subject and dependencies.
Depends on: 1054139, 1082300, 1082440, 1082443, 1082445, 1082453, 1082493, 1082992, 1085292, 1086179, 1087925, 1090803, 1093483, 963541, 964194, 991970, 1003268, 1007724, 1046554, 1047233, 1052309, 1053732, 1055560, 1073421, 1074611, 1087853
Summary: (meta) [NFC] Make NFC Peer APIs available to privileged webapps → (meta) [NFC] Make NFC APIs available to privileged webapps
Can we find someone to own this meta bug? Thanks.
Assignee: nobody → vchang
Target Milestone: --- → 2.2 S6 (20feb)
All the dependent bugs are fixed, let's close this.
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Hi Yoshi, can we close this bug? It looks like all the dependency bugs are fixed in 2.2 and m-c.
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago → 3 years ago
Resolution: --- → FIXED
I've gone through the MDN docs and made sure that it is clear that NFC is privileged in 2.2+. https://developer.mozilla.org/en-US/docs/Web/API/NFC_API https://developer.mozilla.org/en-US/Apps/Build/App_permissions
Keywords: dev-doc-needed → dev-doc-complete
You need to log in before you can comment on or make changes to this bug.