VastParser#trackErrorEvent() mutates DEFAULT_EVENT_DATA
mseeley opened this issue Β· comments
Hi DM humans π:)
Reading through the source I found the following usage of Object.assign
:
vast-client-js/src/parser/vast_parser.js
Lines 80 to 86 in 19223a0
Object.assign
will transform then return the first argument, in this case DEFAULT_EVENT_DATA
.
The current approach is only safe if the data
argument has a fixed interface. Usages of trackErrorEvent
in the parser provider different data
shapes. So, if trackErrorEvent
is called twice then the second call can contain data from the first call. It may not be typical for a parser to emit multiple errors but it looks like a parser instance can be long lived and asked to parse
multiple vastXml
objects.
Anyway, easy fix is to provider an empty object as the first param Object.assign({}, ...
or shift to a spread syntax.
The same behavior is also present in VastClient
:
vast-client-js/src/vast_client.js
Line 95 in 707e854
I think it would be unexpected for get(url, optionsA)
to change this.defaultOptions
such that get(url, optionsB)
winds up using a mix of defaultOptions
, optionsA
, and optionsB
.
If it's helpful, here's a CodePen that demonstrates the underlying issue.
Hi, you're definitely right, we are mutating DEFAULT_EVENT_DATA
and this.defaultOptions
. Using spread syntax would be quite alright as a fix. Would you be interested in contributing to our amazing vast-client? If so, please follow our contributing guidelines. Great job in spotting this :)
Hi @kobawan, sure thing. I'm happy to.