1028767 - The device cannot deliver the valid URL by using NFC Paring in v1.4 branch

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: NFC, defect)

Description

[LEE.WJ]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140506152807

Steps to reproduce:

In v1.4 FFOS device, 

1. Lunching browser app, and connect to "mozilla.org" site.
2. To share URL, tapping the device together to enable NFC.
3. When the screen moved backward, the user swipes up to share the URL.
4. The URL ("mozilla.org") is delivered to the other side device, then the other side device will receive it and lunching browser app with this URL.

* we checked about reasons of delivering invalid URL as below.
  - The parameters of "new MozNDEFRecord" has valid data in nfc.js (gaia/apps/browser/js/)
  - But we found these parameters were not valid in MozNDEFRecord::MozNDEFRecord (gecko/dom/nfc/MozNDEFRecord.cpp)
  - And if TypedArray.h (gecko/dom/bindings) file moves to previous commit that was applied by [e-mail], Mar 10, the device can deliver valid URL by using NFC paring.


Actual results:

The device delivers invalid URL (null url) to other side device.


Expected results:

The deivce delivers valid URL ("mozilla.org") to the other side device
Then the other side device receives it, and lunching browser app with this URL ("mozilla.org")

Comment 1

[Youngwoo Jo]

dom/nfc/MozNDEFRecord.cpp is using Uint8Array as a parameter type.
However, the Uint8Array typed values are passed from javascript-side with the incorrect values.

Jeff Walden, I saw you commited the latest modification into TypedArray.h.
As the above issue description, if your latest commit to TypedArray.h is reverted, payload(including URL) of MozNDEFRecord is passed with the valid URL, correctly.
Moreover, bug 999651, bug 995679, bug 1009952, bug 1011007 and bug 991981 could not be accessed by the public access right, so I could not read the details of your commit.

Jeff Walden, Could you analyze this issue?

Comment 2

[Boris Zbarsky [:bzbarsky]]

Let's try the right address for the needinfo.

LEE.WJ, which of the three typed array arguments is wrong?  Or is it all of them?

Is the length wrong, or the contained data, or both?

Comment 3

[LEE.WJ]

All of three typed array arguments have wrong values below.

 : aType.Length() is 0, aType.Data() is null.
 : aId.Length() is 0, and aId.Data() is null.
 : aPayload.Length() is 0, and aPayload.Data() is null.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Thanks!  Just to check, is the relevant constructor call happening within a single global, or over Xrays?  At first glance this is hapening normally, right?  And ids should be expected to be 0-length, rtdURI should be a length-1 array containing the charcode for 'U', correct?

Comment 5

[Boris Zbarsky [:bzbarsky]]

Also, just to check, which actual Gecko revision are you seeing the problem with?  Are you on mozilla-central or on some branch?

Comment 6

[Jeff Walden [:Waldo]]

Length()/Data() being 0/nullptr sounds like a neutered array to me.  Or, more likely, as bz suggested on IRC, forgetting to call ComputeLengthAndData() before calling Length() and Data().  Are you doing that?

I note for the record that if b2g were testing debug builds, failure to call CLAD would trigger an immediate assertion that would make this usage error stick out like a sore thumb.  I'M NOT BITTER, WHY WOULD YOU THINK SO?  ;-)  :-\

Comment 7

[Boris Zbarsky [:bzbarsky]]

Oh, I bet you're in Gecko 30?

This looks like bug 1018068, which apparently didn't get backported to all the relevant branches?

Comment 8

[Jason Smith [:jsmith]]

Note - NFC was cut from 1.4, so this shouldn't be needed on that release. We only support NFC on 2.0 & later.

Comment 9

[Lawrence Mandel [:lmandel] (use needinfo)]

Not tracking on Firefox releases as this is limited to Firefox OS. I have marked 2.0 and 2.1 as affected as per comment 8.

Comment 10

[BMO Automation]

Firefox OS is not being worked on