Hi! This only happens in very specific cases, and to be honest block widgets are probably better for my use case (though I’ve been avoiding moving to them for a separate reason), so I was second guessing whether to report this or not, but thought I’d leave the decision to fix (or not) for maintainers.
When replacing multiple lines, a tall inline widget whose position is out of view is recreated when selection is updated via a click event. So it doesn’t happen when moving with right or left arrow keys, or when just replacing one line. Here, lines 7 and 8 are shown if the cursor is inside line 7’s from -2 until line 8’s to + 2. There’s no issue toggling between the replacement widget when the viewport is at the top of the document, but when it’s at the bottom, widget toDOM is called. Here’s the same code except the replacement is for one line only, where toDOM is not called again.
The editor guesses the content it needs to draw incorrectly, because the huge widget is throwing off its expectations. That causes it to first update the viewport to not include the widget, and then, finding out that that draws too little content, redrawing again, including the widget again. Adding an estimatedHeight property to the widget type helps.
Adding estimatedHeight as a fixed value did help! However for cases where height might vary, I tried setting the estimatedHeight from the height of the widget element. But it looks like at least in this case of replacing at least 2 lines, a new widget type instance is created and the estimatedHeight is taken from that instead of the currently displayed widget type instance. Is this correct? And in this case creating block widgets instead of inline widgets is the cleanest solution?
Edit: I guess putting a high enough estimated height might work too and the editor can just update if the estimated height is too large. Is this okay/an intended use of estimatedHeight too?