Should glimmer catch DOM NotFoundErrors when removing elements? #736
Comments
|
Sorry for the late response, this was brought to my attention on Discord today. I think this can be closed now, as ember-fastboot/ember-cli-head#45 seems to have addressed the issue in However, I think this is a genuine error in the user code and we shouldn't just silently ignore it. Essentially a piece of glimmer-vm owned/managed DOM was mutated/removed by foreign code and that's generally not supported/undefined behavior. It seems like ember-cli-head was able to avoid triggering this scenario in the first place which is the right thing to do. This error (which could be less cryptic) is just one of the symptoms caused by the unsupported/unexpected DOM mutation. Even if we silenced it here, it will likely cause other problems (and be even more difficult to debug when it inadvertently moves the problem somewhere else). |
I recently spent some time debugging a rash of
Cannot start a nested transactionerrors like those described in #484. Specifically (like #484 (comment)) these errors were fallout from an uncaught NotFoundError DOMException raised when Bounds#clear tried to remove a node from the DOM that had already been removed.What turned out to be happening was:
{{head-layout}}into the document<head>.ember-cli-head, so this sneaky instance-initializer ran when the engine loaded and gleefully smashed away all the{{head-layout}}DOM nodes.{{head-layout}}component failed (presumably because the DOM was gone)DOMException: NotFoundErrorWhile this is somewhat of an edge case, it leads me to think that the glimmer VM might want to handle the possibility of DOM-gone-missing whenever it uses
removeChild.Does it make sense to catch these DOMExceptions, since they seem to indicate that the removal has already happened? Or maybe to guard against them by verifying the node's
parentis set before callingremoveChild?The text was updated successfully, but these errors were encountered: