What is safety consern about Uint32Array::view exactly?

[Maximkaaa]

There is this text in the docs:

Views into WebAssembly memory are only valid so long as the backing buffer isn’t resized in JS. Once this function is called any future calls to Box::new (or malloc of any form) may cause the returned value here to be invalidated.

Can anyone explain what this means exactly. How can Uint32Array be invalidated while I own &[u32] and don't change it? How would a random Box::new call move my, say, Vec<u32>. Even more, I would expect that if I do something like

let vec = vec![1, 2, 3];
let array = Uint32Array::view(&vec);
std::mem::forget(vec);

than my array will be valid indefinitely (assuming I don't care about memory leak here).

Do I get something wrong about memory management in wasm?

[Liamolucko]

The problem is that Box::new might cause Wasm memory to get bigger, and when it does that all the existing references in JS get replaced with empty Uint8Arrays ('detached').

See https://developer.mozilla.org/en-US/docs/WebAssembly/JavaScript_interface/Memory/grow#detachment_upon_growing (that's talking about Memory.grow in JavaScript, when it's the memory.grow instruction that gets used by Box, but it works the same way).