fix!: Normalize Zelos connection indicators

[gonfunko]

The basics

• I validated my changes

The details

Resolves

• Fixes Zelos does not support input outlines around filled inputs - causes preview weirdness #3659
• Fixes Provide connection previews when connecting a moving value block's input to an existing block (zelos) #9338

Proposed Changes

This PR cleans up Zelos' display of proposed connection indicators. Previously, proposed input connections indicators had three possible appearances:

Fuzzy, when an existing block would be replaced

Normal, when a block would be connected to an empty input

Skinny, same circumstances as above but when the highlight ring happened to be z-ordered below the fill for the input slot.

Likewise, next/previous connection indicators could appear normal, or partially obscured by the insertion marker depending on the whims of z-ordering:

Now:

• The "replacement fade" (fuzzy) filter has been entirely eliminated; the connection highlight for replacing a block appears the same as the highlight for inserting a block into an empty input connection
• Connection highlights are always brought to the front, so the skinny/obscured appearances are eliminated. This also normalizes them and makes them consistently prominent for Geras/Thrasos.
• Input connection highlights are shown in Zelos on both the dragging and stationary block, as appropriate; previously, if the block being dragged was aligned in such a way that it was eligible to connect to an input on a stationary block, there was no visual indication of this.
• BlockSvg.highlightShapeForInput() has been removed, as it was internal and had no callers.

Breaking Changes

• REPLACEMENT_GLOW_COLOUR, REPLACEMENT_GLOW_SIZE, and replacementGlowFilterId have been removed from Blockly.zelos.ConstantProvider. References to these fields should be removed; the appearance of the connection indicator can be styled with CSS targeting .blocklyHighlightedConnectionPath.
• IPathObject.updateReplacing() has been added; this method is optional and the root PathObject defines it by simply toggling a class, so this should not strictly be breaking, but custom renderers may wish to implement/override it.

[BenHenning]

I haven't looked at this in depth quite yet, but how are highlights now consistently brought to the front to fix the z-ordering issue, and does this introduce any problems with keyboard navigation? I remember digging into this before and I found that the standard bringToFront will break focus since it changes the DOM and many DOM operations just completely reset focus back to the document body. I think we built some resilience to this failure type in places (and maybe in FocusManager itself) but I would need to dig to confirm.

Edit: Ah, #8981 was the one that may have made this work. I'm still curious about the first part, though, because I don't see bringToFront used anywhere.

[BenHenning]

Other than my specific concerns on focus this seems like an excellent simplification.

[BenHenning]

This might cause focus loss problems. I'm also curious why this is necessary--shouldn't the highlight SVG already be properly parented since it exists in the DOM at this stage?

Or is this the means to try and 'bring it to front'?

[gonfunko]

Yes, this is the means to bring it to the front. Experimentally, there don't appear to be any focus issues, I think because the highlight SVG is not itself the thing that has focus; I was able to move blocks using keyboard nav and Zelos and it behaved as expected.

[BenHenning]

Wait that's slightly confusing as well. The highlight SVG should definitely hold focus but perhaps this case isn't hit today because we can't actually navigate to the connections themselves. I wonder if focus would still behave correctly if we temporarily re-added connections to possible navigable locations.

[gonfunko]

I don't think that makes a difference; the highlight SVG is the focusable element for the connection, but this is run in two situations: when the connection is being highlighted as a potential connection point, in which case the focused thing is the block being dragged, or in response to onNodeFocus() being called, which the focus manager invokes prior to actually focusing the element, so the DOM shuffle happens before focus gets assigned.

[BenHenning]

Sorry this dropped off my radar @gonfunko. Just followed up to the comment thread.

It also seems like CI is failing--might be worth taking a look in case there are any issues with the PR changes.

[gonfunko]

@BenHenning No worries, I also replied in the thread just now. CI failures are across all of v13, the closure compiler dep just needs to be updated.