New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 803082 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Last visit > 30 days ago
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug



Sign in to add a comment

cancelPush during a push is unpredictable and can erase tags

Reported by alanbell...@gmail.com, Jan 17 2018

Issue description

Steps to reproduce the problem:
component is Blink>NFC but that isn't in the list of options
1. set up a watch, so a callback happens on reading tags
2. in that callback issue a nfc.cancelPush()
3. Set up a push of some data with options={ignoreRead:false};
3. observe that the read callback is fired when approaching a tag, and the tag may end up with the new data or it may erase the tag

What is the expected behavior?
either the original data stays on the tag (which I would prefer) or the new data is written to the tag.

What went wrong?
Sometimes it erases the data on the tag

Did this work before? No 

Does this work in other browsers? Yes

Chrome version: 63.0.3239.111  Channel: stable
OS Version: 7.1.2
Flash Version: 

spec for cancelPush is here https://w3c.github.io/web-nfc/#cancelPush and it does say that it will not interrupt transfers - but erasing the tag isn't an expected outcome.

The use case is that I want to append records to a tag, so when writing I want to check that the tag I am about to write to is the correct one, and abort if the user attempts to write back to a different tag.
 
cancel.html
1.6 KB View Download
Cc: alexande...@intel.com
Components: Blink>NFC
Adding component, taking a stab at a relevant cc.
Cc: -alexande...@intel.com
Owner: alexande...@intel.com
Status: Assigned (was: Unconfirmed)
it further appears that it is not validating tags as set in 14.2 of the push method
 https://w3c.github.io/web-nfc/#the-push-method

"If the Web NFC message origin of the read NFC content is null, or it is different than the ASCII serialized origin of the incumbent settings object, and the obtain push permission steps return false, then reject promise with "SecurityError" and abort these steps."

not sure if this should be considered a separate issue, but I think the intent of this is that web tags associated with one site shouldn't write when presented with a tag that has data belonging to another site - it doesn't appear to be doing this step.
Owner: kenneth....@intel.com

Sign in to add a comment