Buffer.from($('myinput').val(),'hex') produces unpredictable results

[stevegrove]

I have a simple test case where I am trying to use the value (a hex encoded string) from a DOM input field as the parameter in a Buffer.from(str,'hex') call. I have noticed that if I change the value of the DOM input, occasionally the buffer returned from the call is empty although the string from the DOM is not. If I copy the value from the DOM into a temporary Buffer as 'utf8' first then use Buffer.from(TempBuffer.toString(),'hex') then all is fine. There are other workarounds such as copying byte by byte which I have included in the attached files.

All the input strings are valid hex representations so it is not a parsing problem.

I have created a simple test GUI that shows the problem on Windows and Linux x64 (attached).
buftest.zip

A reproducible failure is to run the attached test GUI using a late nwjs SDK

/pathto/nwjs-sdk-v0.15.4-linux-x64/nw .

1. run GUI (image 1)
   

2. Press "Manual" button - output will show that DOM input string "1234" is correctly decoded as 'hex' then converted back to a string using myBuf.toString('hex') using various methods of copying. (Images 2,3,4)
   
   
   

3. Edit the input field to "12345678"

4. Press "Manual" button - output will show that DOM input string "12345678" is NOT decoded as 'hex' and resulting const myBuf = Buffer.from(inhex,'hex'); is empty. Note 'inhex' variable is the parameter passed in from the DOM input field $('#testhex').val().trim().substr(0,16) and is DEFINITELY NOT empty. (Images 5,6,7)
   
   
   

5. Repeat the steps above but instead press the "Manual Test Copy" button and everything works fine and as expected - this test copies the DOM input value into a buffer before passing to the test function.

6. Also note - you can edit the input back to 1234 and it now fails! (Images 8&9)
   
   

If, however, I edit index.html and set the initial value of 12345678, then decode 'hex' works fine until I edit it as shown below.

7. If the initial edit is to make the string smaller say from "1234" to "12" then 'hex' decode seems to be fine so it looks like there is an issue when I increase the size of the string past its original length.
8. Is NWJS doing some kind of integer conversion of the string when used in the Buffer.from() call? I ask because if I simply force a string using a temporary variable it works as expected every time.
9. Edit index.html with initial value "1234567890" and experiment removing and adding pairs of digits then pressing "Manual Test" - not the erratic behaviour of the field that uses the input value directly in the call to $.test().
10. The code below produces the same string in "inhex1" as in "inhex" yet works every time is "inhex1" is used as the string in Buffer.from(inhex1,'hex')

var pad = "0000000000000000";

// pad the end with 00 then remove them (fake it)
var inhex1 = (inhex + pad).substring(0, inhex.length);

[rogerwang]

@ghostoy could you confirm is this the same with the one we fixed before? nodejs/node-v0.x-archive#8683

[ghostoy]

@rogerwang Yes, similar issue. I will submit a PR to fix it.

[stevegrove]

@ghostoy @rogerwang thanks for looking at this. The issue you reference looks as if it would fail all the time for particular strings. The behaviour I observe is that it works for the initial value of the DOM element then fails if I edit the DOM input. Also, if I copy the DOM input to a temporary buffer it works every time no matter what the input. Here is a cut down version of my test code.

click "Test" and observe "1234" in both myBuf and myBufCopy PASS
edit input to "1235" click "Test" and observe empty myBuf and "1235" in myBufCopy FAIL

also

edit input to "1235" before clicking "Test" and observe empty myBuf and "1235" in myBufCopy FAIL
now you can't even revert the input to "1234" and get that to decode

buftest-simple.zip

In my tests with node alone I could not get it to fail which is why I though it was the DOM element that was the differentiating factor as obviously can't use DOM data without nwjs.

[rogerwang]

@stevegrove I think we had this issue when DOM and Node uses different internal representations for the string. Will fix it soon.

[rogerwang]

This is fixed in git and will be available in the next nightly build.