Closed Bug 1018068 Opened 7 years ago Closed 7 years ago
[NFC] NFC sharing does not work
Gaia b669dd2cc321f37cebc7081a79b968cac36b4200 Gecko https://hg.mozilla.org/mozilla-central/rev/b85b57f05fda BuildID 20140529160204 Version 32.0a1 STR: 1. enable NFC on both phones 2. open URL (or contact, files) 3. tap two phone, slide the shrinking UI to share Expected result: receiver can receive what sender sharing Actual result: receiver receive nothing
It worked before, right? When doesn't it work.
Yes, this problem should start from the following build: Gaia 4142df90c71abdc1e3a87cd37dff1a22d5e38b34 Gecko https://hg.mozilla.org/mozilla-central/rev/bc995dc1ea09 BuildID 20140528160204 Version 32.0a1
Dimi, Do you find anything?
I was looking into this while doing builds for my new flame device. I've made a build mentioned in Comment 2. Few findings: - NDEF receiving works well. I've tested with Android device and could share contact and url from Android to Flame. - There is a problem with sending NDEF. In the attached log you can see that NFC:WriteNDEF has wrong records without type and payload. While doing share from flame to Android it results in Unsupported tag message. At first glance it seems like a problem with MozNDERRecord. I've started adding additional loging in the browser app and it seems MozNDEFRecord is empty immediately after being created, but need to confirm this after looking closely.
This issue happened because of TypedArray is changed in changeset: http://hg.mozilla.org/mozilla-central/log/57b0932e2f06 I'll provide patch to fix it.
Hi Jeff, This issue seems related to changeset mentioned in Comment 5. Could you help review this patch ? Thanks!
Attachment #8433272 - Flags: review?(jwalden+bmo)
Comment on attachment 8433272 [details] [diff] [review] Bug_1018068_v1.patch Review of attachment 8433272 [details] [diff] [review]: ----------------------------------------------------------------- Yeah this is fine. Is this file only built in b2g configurations or something? I had patchwork that renamed the Length/Data accessors, to be sure I'd adjusted every caller, that built fine for me locally (but which I never intended to land, of course).
Attachment #8433272 - Flags: review?(jwalden+bmo) → review+
From moz.build, yes: if CONFIG['MOZ_NFC'] > Is this file only built in b2g configurations or something?
To be more precise, not every platform has NFC compiled in. gecko/configure.in has the conditional config per general platform, and device/<mfg>/<device name>/device.mk for runtime enabling of nfc for platforms that have NFC hardware: PRODUCT_PROPERTY_OVERRIDES += \ ro.moz.nfc.enabled=true
Hm. Its crashing on the new .ComputeLengthAndData() for me (type field): master head: 691bac9c467fe1385dbd2d1318f1b4be4e23d2c8
(In reply to Garner Lee from comment #10) > Hm. Its crashing on the new .ComputeLengthAndData() for me (type field): > master head: 691bac9c467fe1385dbd2d1318f1b4be4e23d2c8 Hi Garner, How did you reproduce this bug ? It works fine in my environment with latest master.
Works ok on my flame with latest gecko master (cbe7e9c7e767ee6ce0459b519b4de2292b3cbd60).
Target Milestone: --- → 2.0 S3 (6june)
Assignee: nobody → dlee
> Hi Garner, > How did you reproduce this bug ? It works fine in my environment with > latest master. Yes, but only in a feature I'm working on. There's a sec bug open on it (I'll add you to it).
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Verified on Device Flame (Nexus 4) Gaia 2e5636e852a9354a5f8072b179cf16f72647cfd6 Gecko https://hg.mozilla.org/mozilla-central/rev/8bd92dc9ef59 BuildID 20140608160201 Version 32.0a1
Status: RESOLVED → VERIFIED
Doesn't this need backporting to all branches bug 991981 was checked in on?
Those branches would be b2g30, b2g28, and b2g26, to be clear.
NFC feature is enabled only after 2.0, so we don't have to backporting for this issue.
Then what is bug 1028767 about?
Partial NFC has been also applied into gecko v1.4(b2g30) branch. (I don't know how partial it's applied) And browser app provided by gaia v1.4 is also supporting NFC feature. So, this issue not only occur in v1.4 branch(b2g30) but also should be fixed.
You need to log in before you can comment on or make changes to this bug.