Image occlusion mask editor only loads for the first created note

[glutanimate]

Follow-up to #2485

With the latest main build, the IO mask editor disappears as soon as you attempt to create a second note:

black-io-editor.mp4

The console log and stdout seem clean, did not see any error messages.

[dae]

Thanks, looks like an unintended side-effect of the Svelte refactoring.

[glutanimate]

@dae Thanks for the quick fix! This works well when using the image selection button. However, now that I'm starting to tinker with programmatically launching the editor into IO mode, I'm finding that I'm running into the same issue as before.

My code is using the updated python API in #2598, but I can also reproduce the issue on main.

Essentially, I'm skipping the image selection step prompted for by the button and calling setupMaskEditor directly with a predetermined image. As a result, the imageOcclusionMode reset you added in 1d75598 is skipped over, which I assume explains why the problem resurfaces. FWIW, the behavior is exactly the same as the user-interaction mediated trigger above, i.e. calling setupMaskEditor works fine the first time before the mask editor has been invoked at least once in a session, but then fails subsequently when trying to switch back from e.g. a basic note type.

Given the fix above, the first thing I tried was adding the same reset to setupMaskEditor, i.e. setting imageOcclusionMode = undefined at the top, but unsurprisingly this didn't work. I assume the problem is that a re-render is not triggered quick enough, right? Changes applied at button onClick time have a lot more time to play out of course, given that the user moves on to select an image, etc.

With that in mind, do you think there's another way we could approach this perhaps? Still getting up to speed on Svelte, so I don't have a full overview of how the rendering lifecycle works.

[glutanimate]

OK, nvm, I think #2599 should do the trick - writing things out always helps 😅

[dae]

I assume the problem is that a re-render is not triggered quick enough, right?

My guess as to what's happening here: if there's a delay between the mode being unset and set to a different value, the existing image occlusion component is removed from the DOM. If the mode gets changed without being first removed, the existing component is removed, and presumably it's in an inconsistent state then. If we need to force the existing component to be removed first, we could probably do so by awaiting tick() before setting a new non-null value.