I don't think the problem is whether JS deallocates it or not (which is what I assume you mean by giving it back or not). I think you give out dangling references to JS to begin with. I believe data is dropped in wrapper_vec_to_js_array, causing the Float64Array views you create to point to data that got dropped before you even hand over the array to JS.
I think this is a violation to the last paragraph of the safety section of the docs of Float64Array you've linked:
Finally, the returned object is disconnected from the input slice’s lifetime, so there’s no guarantee that the data is read at the right time.
It's pretty clear from the signature, though (and that's even better). If the function wanted to assume ownership, it would have taken an owned value (e.g., Vec<f64> or Box<[f64]>) to ensure correct ownership structure by means of the type system, or at the very minimum, a raw pointer (*mut f64 or *mut [f64]) in order to indicate ambiguity. Since the function takes a slice, it's unambiguously not trying to deallocate your array (since deallocating arbitrary slices is wrong, because a slice doesn't necessary come from a heap allocation).
The problem @jofas is trying to point out is this:
Here, you give ownership of data to this function, which means that it's dropped before the function returns. Consequently, any references pointing into it will be invalid immediately, by the time you even obtained the return value.
The immediate fix would be to accept a borrowed slice instead of an owned Vec. (That doesn't resolve some other safety concerns, though, eg. the prohibition of heap-allocating while JS has the array view). But it would not be unconditionally wrong, at least.