Steps to reproduce: 1. Launch emulator-jb 2. Connect via telnet 3. Setup remote end point and LLCP 4. Issue: nfc snep put -1 -1 [208,1,VQ,BmthbWl0dWVsQGdtYWlsLmNvbQ,A] (flags=MB,ME,SR; tnf=1; type='U', payload='mailto:kamituel@gmail.com', id=A) What should've happen: Mail app should be launched. What happened: Nothing. NfcManager.handleNdefDiscovered() called MozActivity, which failed.

Support for mailto: URI with unit tests. Also unit tests for tel: URI (because those two cases are similar).

Alive, I've flagged you for review - my PR is the most straightforward way of making this work. I'm wondering whether it's the best way, though. As of current implementation, handling NDEF messages with tnf = TNF_WELL_KNOWN and type = 'U' requires us to make a decision on how to construct MozActivity params based on the URI type from message. For instance, if message contains URI "http://.*", we set activity name to "nfc-ndef-discovered" and data.url to URI from message. For URI "tel:", we set activity name to "dial", data.uri to URI from message. For other URI's we set activity name to "nfc-ndef-discovered", but we do not set data.url, but rather data.uri. All that's because respective apps, in their manifests, use inconsistent "activities" entries. For instance, dialer has the following entry: > "dial": { > "filters": { > "type": "webtelephony/number", > "number": { "pattern":"[\\d\\s+#*().-]{0,50}" } > }, > "href": "/dialer/index.html#keyboard-view", > "disposition": "window" > } while Browser uses something completely different: > "nfc-ndef-discovered": { > "filters": { > "type": "url", > "url": { > "required":true, "pattern":"https?:.{1,16384}", "patternFlags":"i" > } > } > } Couldn't we just always send something consistent, like set activity name to "view", set data.uri to URI from the tag and let specific apps handle logic themselves? This could require tuning manifests for Browser, Email or Communications. What do you think?

(In reply to Kamil Leszczuk from comment #2) > Alive, I've flagged you for review - my PR is the most straightforward way > of making this work. > > I'm wondering whether it's the best way, though. > > As of current implementation, handling NDEF messages with tnf = > TNF_WELL_KNOWN and type = 'U' requires us to make a decision on how to > construct MozActivity params based on the URI type from message. > > For instance, if message contains URI "http://.*", we set activity name to > "nfc-ndef-discovered" and data.url to URI from message. > > For URI "tel:", we set activity name to "dial", data.uri to URI from message. > > For other URI's we set activity name to "nfc-ndef-discovered", but we do not > set data.url, but rather data.uri. > > All that's because respective apps, in their manifests, use inconsistent > "activities" entries. For instance, dialer has the following entry: > > > "dial": { > > "filters": { > > "type": "webtelephony/number", > > "number": { "pattern":"[\\d\\s+#*().-]{0,50}" } > > }, > > "href": "/dialer/index.html#keyboard-view", > > "disposition": "window" > > } > > while Browser uses something completely different: > > > "nfc-ndef-discovered": { > > "filters": { > > "type": "url", > > "url": { > > "required":true, "pattern":"https?:.{1,16384}", "patternFlags":"i" > > } > > } > > } > > Couldn't we just always send something consistent, like set activity name to > "view", set data.uri to URI from the tag and let specific apps handle logic > themselves? This could require tuning manifests for Browser, Email or > Communications. What do you think? I don't really understand what's your proposal. I guess your idea is to mess NDEF with WebActivity ..? I don't think a solution involving manifest change will work for 'all apps in the world'..

No, my idea is quite reverse - not to mess NDEF with WebActivity ;) It's messed right now, IMO. Look at browser/manifest.webapp (for instance): actiivty name there is "nfc-ndef-discovered". This app has special logic only to handle sharing URL's via NFC, while it should be handled by existing activity "view". Those two activities are exactly the same, beside their name. My proposal is for NfcManager, when handling URI NDEF messages, to always call MozActivity with: - activity name set to "view" - data.uri set to decoded contents from tag (i.e. "mailto:jorg@borges.ar", "http://mozilla.com" or "tel:00481234567"). Look at NfcManager.formatURIRecord() - the whole switch there should not be necessary, IMO. I would rewrite it to something like: > formatURIRecord: function nm_formatURIRecord(record) { > var prefix = NDEF.URIS[record.payload[0]]; > if (!prefix) { > return null; > } > > var uri = prefix + NfcUtils.toUTF8(record.payload.subarray(1)); > > return { > name: 'view', > data: { > uri: uri > }; > } And that's it: don't use data.url, don't set "data.number" for "tel:" uri etc. As far as I understand, this is how Android handles NDEF URI tags.

master: https://github.com/mozilla-b2g/gaia/commit/0875a950a059628a2790ca7d835fe17f309c62d8