fix: Ensure visual indicating for focus loss.

[BenHenning]

Fixes #92

If the workspace loses focus, any existing block selection or cursor visuals should be hidden to represent that the focus has been lost. Instead, the passive indicator should be shown so that the user has context on where they are returning when navigating back to the workspace.

This changes the hide behavior for the line cursor to also clear any block selection that may be present (since the cursor is using selection as a means of visually highlighting blocks today).

There was an issue restoring selection due to the passive focus indicator interfering with block selection (since it was using selection). This was updated to use non-selection CSS to keep the indicator without affecting the selection state. This pulls in the changes from #236.

See video for the new state:

Screen.recording.2025-03-11.4.15.41.PM.webm

[BenHenning]

@rachel-fenichel would be nice to get your thoughts on the experience. From what I can currently tell, the passive indicator doesn't seem 100% consistent as to what shows when in the toolbox (or outside keyboard nav focus entirely), so it would be helpful to get clarity on whether the video above is ideal or, if not, what the ideal experience should be.

@cpcallen would like your thoughts on the passive indicator as well--I lack the context as to how it's meant to work. It confuses me that we're using the selection indicator for representing 'passive' focus at the moment since it's the same visual representation as active (and thus doesn't really communicate a difference to the user).

[microbit-matt-hillsdon]

I didn't expect us to lose the context of where a block would go when the flyout is opened. Previously there was a mixed approach to this, with the blue marker for next/previous and what looks like the normal cursor outline for other positions. But I think it did an important job.

The UI now looks the same in two scenarios: starting from the toolbox & starting from e.g. a next connection on the workspace, but inserting a block with Enter will behave differently.

Absent another proposal, I think we see active focus as outline around the area + the cursor/selection rendering, and passive focus as just the latter.

[rachel-fenichel]

The passive focus indicator should show when the active focus moves to the flyout/toolbox. Agree that losing it seems like a problem. I'm fine with Matt's proposal that "we see active focus as outline around the area + the cursor/selection rendering, and passive focus as just the latter".

I implemented the passive focus indicator (as it currently exists today) and can give the context you asked for.

The passive focus indicator is different from the cursor in two ways:

• The passive focus indicator can be null. That's not true for the cursor and wasn't true for the marker, which is why the marker would persist in annoying locations.
• The target (block or connection) doesn't know about it. That means that if the target block gets updated or rerendered, it doesn't know to force a rerender of the passive focus indicator.

In implementing the current passive_focus.ts my primary goal was to allow it to be set to null. I implemented showAtBlock and hideAtBlock in a minimal way, by calling the block's addSelect and removeSelect. That's why it looks the same as the cursor selection, which I agree is confusing. It was never intended to be permanent: #212 tracks making it more distinctive.

I just added a draft PR #236 that makes the passive focus indicator distinctive on blocks, and makes both block and next connection indicators controllable with CSS. Please don't merge it with the current colours, but adding that code into your workspace may make it easier to see when you have passive focus and when you have active focus.

[BenHenning]

Currently stuck on trying to pull in #236 as it seems that the CSS style cannot always be reliably reset:

Screen.recording.2025-03-05.2.29.35.PM.webm

Enabling the passive focus indicator does correctly show up with a dashed line, but navigating back to it (i.e. refocusing it) causes the dashed line to stay even with the selection indicator from core. What's confusing is that I've verified that the stroke dasharray has been correctly set to 'none' when selection returns, so I have no idea why it's not updating correctly.

[BenHenning]

Thanks @rachel-fenichel @microbit-matt-hillsdon and @cpcallen. Please take a look at the latest video and follow up if you have any concerns.

Rachel: you mentioned in #236 that we should pick a different color. Might you (or anyone else) have any specific suggestions? I suppose we could use the same selection color now that the (current) passive indicator style is dashed, and maybe lower its stroke width slightly so it's thinner than the selection indicator.

[rachel-fenichel]

I suppose we could use the same selection color now that the (current) passive indicator style is dashed, and maybe lower its stroke width slightly so it's thinner than the selection indicator.

Works for me!

[microbit-matt-hillsdon]

I was initially surprised that switch to passive focus in the workspace when a context menu or field editor is opened. Logically it makes sense, but there's something a bit weird about the feeling that a value block gets "less selected" when you try to interact with it. Not arguing against this, just sharing in case others feel similarly.

Deployment that I tested (as of 2463303619a2defa305e39cc11cacd85aa8b96c9).

[cpcallen]

@microbit-matt-hillsdon: I agree that this is slightly surprising, but actual UI will probably change once core Blockly has focus support: when the context menu opens, the block will go from active focus to passive focus, but it should still remain selected.

[BenHenning]

Updated the code & demo video to use a better color (one that @rachel-fenichel suggested--it matches the fully filled indicator).