Build environment: Linux
Moddable SDK version: N/A
Target device: Pebble Time 2 Emery
Description
The @moddable/pebbleproxy v0.2.0 package is erroring out when parsing response headers from fetch requests.
Steps to Reproduce
Apologies for imprecision but we were following the guide at https://developer.repebble.com/guides/alloy/networking/ and running code on the Pebble device.
Stack trace
[PHONE] pebble-app.js:?: Fetch Test:85:18 TypeError: Cannot read properties of undefined (reading 'trim')
TypeError: Cannot read properties of undefined (reading 'trim')
at file:///data/user/0/coredevices.coreapp/files/pbw/pkjs/ea2a7c12-fc5b-4526-a4de-9dcb647f60da.js:314:29
at Array.map (<anonymous>)
at request.xhr.onload (file:///data/user/0/coredevices.coreapp/files/pbw/pkjs/ea2a7c12-fc5b-4526-a4de-9dcb647f60da.js:311:9)
This occurs in the evaluation of 'headers' from https://github.com/Moddable-OpenSource/moddable/blob/public/build/devices/pebble/npm/pebbleproxy/proxy.js#L191.
Suggested fix
I believe this is because the structure of request.xhr.getAllResponseHeaders() is zero or more instances of <header>CLRF such that the last "header" after the split is the empty string, which trips up the following code. I think this can be fixed by calling .trim() on request.xhr.getAllResponseHeaders() before calling .split("\r\n") (and seems to be working for us with a manual patch).
Build environment: Linux
Moddable SDK version: N/A
Target device: Pebble Time 2 Emery
Description
The @moddable/pebbleproxy v0.2.0 package is erroring out when parsing response headers from fetch requests.
Steps to Reproduce
Apologies for imprecision but we were following the guide at https://developer.repebble.com/guides/alloy/networking/ and running code on the Pebble device.
Stack trace
This occurs in the evaluation of 'headers' from
https://github.com/Moddable-OpenSource/moddable/blob/public/build/devices/pebble/npm/pebbleproxy/proxy.js#L191.Suggested fix
I believe this is because the structure of
request.xhr.getAllResponseHeaders()is zero or more instances of<header>CLRFsuch that the last "header" after the split is the empty string, which trips up the following code. I think this can be fixed by calling.trim()onrequest.xhr.getAllResponseHeaders()before calling.split("\r\n")(and seems to be working for us with a manual patch).