`disableOrphans` doesn't work for some keyboard-driven inserts

[gonfunko]

Under Blockly v13, when a block is inserted from the flyout via the keyboard, if the block is immediately committed/added by pressing enter, it will not be disabled. If the block is moved at all - via the arrow keys, or by snapping to grid - after adding it and before committing its location, it will be disabled as expected.

[maribethb]

what's weird to me is that this plugin only modifies the context menu, it does not change the disableOrphans event handler at all. So it seems like something that would be broken in core, not this plugin. Yet I can only reproduce this bug in this plugin and not in main of blockly or in the v13 playground. I don't have an explanation for that yet.

[maribethb]

OK, this is a bug in core in the disableOrphans handler, not in this plugin. The reason I was only able to reproduce it in the plugin is that the bug won't happen if there is a grid and snap-to-grid is enabled, and I just happened to have that enabled in the core playground but not the plugin one.

it's not even really a bug in the disableOrphans handler. The problem is that no final block move event (with dragging=false) is fired in this case. The event queue logic that merges events drops it because it sees the move as being "null" since the block's start coordinates haven't changed. But we do need that final event imo, it would match how mouse moves generate events for new blocks from flyouts.

[maribethb]

On further reflection/discussion, not having the move event makes sense because the block is indeed not moving (while the workspace isn't dragging). so instead had the event listener also run on drag end events.