[Sheet workers] getAttrs returns incorrect default values for selects

Reproduction: Use the following sheet: <select name="attr_test"> <option value="1" selected>First option</option> <option value="2">Second option></option> </select> <script type="text/worker"> on('sheet:opened', () => getAttrs(['test'], v => console.log(v.test))); </script> Expected behaviour:   "1" is logged. Actual behaviour: "0" is logged (regardless of the value of the first option). Once the value is changed and an attribute is created, getAttrs() works as expected (after changing it to the second option and back to the first one, it will return the correct value).

I believe we have experienced this same behavior on the PF sheet.

Lamba functions don't play well with the asynchronous nature of the sheetworkers. If you replace your script with the below do you ever not get the expected result? <select name="attr_test"> <option value="1" selected>First option</option> <option value="2">Second option></option> </select> <script type="text/worker"> on("sheet:opened", function() { getAttrs(['test'], function(v) { console.log(v.test); }); }); </script>

Thanks for taking on this issue Steve! Indeed, using a normal function here instead works and gives the correct default of 1 (but see my response in the other thread). It's a bit confusing though, since selects are the only field where I've seen this issue, and getting the default in a lambda function works correctly for all other types of inputs (though I have not tested textareas).

Jakob, What happens if you use selected='selected' instead of just selected? I haven't run into this issue with the sheet I'm working on, and the only difference I can see is that.

Scott C. said: Jakob, What happens if you use selected='selected' instead of just selected? I haven't run into this issue with the sheet I'm working on, and the only difference I can see is that. Funny enough, I just tried to reproduce my original error with my version of the code, and now it logs 1 as it's supposed to ... but I have definitely  seen this happen, WITH  the original code, so now I just don't know what's what anymore.

Okay, so I cannot reproduce this anymore with either of the two variants above, but I can reproduce it within the Blades sheet even if I switch all the event functions to non-arrow ones. This leads me to think that this might also be some nasty race condition bug like the other one ... I'll try and investigate more until I can get something that at least reliably fails for me.