First off, one of the bug fixes I am suggesting here actually changes the way sheet workers operate. The first observation may break existing sheets, so I'm not sure if it would actually be a good idea to fix it. But I wanted it to be reported anyway. Consider sheet 1: <input type="text" name="attr_test">
<script type="text/worker">
on('change:test', eventInfo => log(eventInfo));
</script>
There's a bit of weird behaviour here: 1. Enter something into the field. Look at the log and observe that eventInfo does not have a previousValue property, instead of event.previousValue === "". 2. Delete the contents of the field. Look at the log and observe that eventInfo does not have a newValue property, instead of event.newValue === "". Consider sheet 2: <input type="text" name="attr_test" value="test" >
<script type="text/worker">
on('change:test', eventInfo => log(eventInfo));
</script>
1. Enter "test2" into the field. Observe that eventInfo.newValue === "test2" (correctly) and eventInfo.previousValue === "test2" (incorrectly). 2. Delete the contents of the field. The field resets to its default value test. Observe that eventInfo does not have a newValue property, despite the fact the new value of the field, as observed by getAttrs and the visual display on the sheet, is "test" and not an empty string. EDIT: In fact, I didn't check and after resetting to default, getAttrs returns undefined as well. But I will take that to a separate bug report.