Workspace comments cannot be edited or tabbed away from

[microbit-matt-hillsdon]

Check for duplicates

• I have searched for similar issues before opening a new one.

Description

3cbca8e breaks workspace comments in two ways:

1. Text cannot be edited as textarea doesn't take the focus
2. You can't tab away from the workspace comment to the next tab stop (focus remains on the comment once on the comment)

These worked in the prior commit.

Reproduction steps

1. npm start
2. "Add comment" (workspace, not block)
3. Click to edit, note you can't get the comment in an editable state
4. Try to tab away, note focus always remains on the comment itself (confirm via document.activeElement)

Stack trace

Screenshots

No response

Browsers

No response

[BenHenning]

I suspect that we need to add a forced tab index somewhere to fix this, but will need to dig a bit more.

[BenHenning]

Hmm 3cbca8e definitely breaks the first scenario (workspace comments not being editable), but tabbing still seems broken even before that commit went in.

[BenHenning]

From bisect: tabbing first broke in 4f3eade (#9082).

Per the investigation above, the failure to be editable first broke in 3cbca8e (#9079) which I also double checked with a bisect.

[BenHenning]

I'm hoping that the editable issue can be fixed by restoring this line: https://github.com/google/blockly/pull/9079/files#diff-6e7284a477e1e313a3e71a87890d6ea7674f895fd21632842738ea83b8dbfab1L68.

The tabbing issue breaking in #9082 is actually very surprising to me because that PR is correcting behaviors. I think there's something very unexpected happening with tabbing for workspace comments that's fundamentally working against FocusManager, and I'm unsure what that is presently. I don't actually understand how tabbing is even navigating to the workspace comment:

• We only manually handle tab for field inputs.
• The workspace comment either has no tab index or a tab index of -1, making it non-tabbable.

[BenHenning]

I'm hoping that the editable issue can be fixed by restoring this line: https://github.com/google/blockly/pull/9079/files#diff-6e7284a477e1e313a3e71a87890d6ea7674f895fd21632842738ea83b8dbfab1L68.

Confirming that this is insufficient--there's more going on here unfortunately.

[maribethb]

When you click on the textarea of the workspace comment, a focusin event is fired, I think twice actually. I don't know why exactly it happens twice, maybe it has something to do with the foreign element part of the workspace comment. Edit: I think it happens twice because the first one focuses the svg element which then causes another focusin event to be fired.

But when that focusin is fired, focusManager tries to focus the workspace comment, which actually focuses the svgRoot of the workspace comment rather than the textarea, so focus is moved out of the textarea and to the svg.

So I can think of a couple approaches:

1. Try to get the focusin event to not be fired when the textarea is focused and we already handle the pointerdown event on the comment (seems tricky as that is some browser business, probably wrong)
2. Put a special case in the focusin event handler in focus manager to not focus workspace comments specifically (might get weird then if you tab over to a window where the comment was the last thing focused though)
3. when a workspace comment is focused, make the textarea the thing that's focused instead of the svg root. (not sure if this has other consequences)

Since there's not an obvious answer I'm not sure what to do next but will discuss with Ben. I did confirm that doing option 2 (super hackily) does fix both problems reported in this bug though.