firefox can't focus code editor

[kmcnaught]

The current code (13bc494) had some last minute hacks to (a) remove an extraneous tab stop before the editor and (b) change the focus indicator for tabbing to the editor. I presume (a) is buggy (i.e. 3100903) because I can't tab to the code editor on Firefox. I'm not sure what the behaviour was before those 2 commits.

Here's a 30 second loom video comparing the two behaviours

Firefox 132.0 (64-bit) on Windows 11.

[cpcallen]

Tentatively assigning this to Ben as it relates to the work he is doing fixing tabbing more generally.

[microbit-matt-hillsdon]

This also applies to Safari. I think the difference is that Chrome will focus elements with a focus listener that it otherwise would not, but for other browsers you need tabindex. I experimented with this in this sandbox.

The extra tab stop appears to be back for the same reason since #156.

[microbit-matt-hillsdon]

Recent focus work has helped here but there are still serious issues and some Firefox/Safari review is needed.

The most glaring issues

Move mode appears to be broken with a logged message "Trying to focus a node that can't be focused."

This affects insert and 'M'.

Clicking on a block doesn't correctly enable keyboard navigation (e.g. can't press 't' to open toolbox). Repro:

1. Open local build of demo in Safari (I tested against e34a9690eddf4512f682aa80c697211123326a7c of blockly)
2. Click on "create canvas" block
3. Try to navigate or open toolbox
4. Click on a different block, note same issue
5. Click back to "create canvas", note keyboard nav works now

There are also default styles for focus that I'll look at on #511,.

I think these suggest fundamental issues and someone looking at focus changes should take a look soon to unblock further Firefox/Safari testing.

[BenHenning]

Thanks @microbit-matt-hillsdon that's very helpful. I can confirm that in Firefox tabbing to the workspace works fine, but the exact same problems that you see in Safari also seem to be affecting Firefox. These aren't completely new failures as we had versions of them with Chrome in the past, so I'll dig and figure out what's happening here.

[BenHenning]

So some investigation results: it seems that the warning of trying to focus an unfocusable thing is probably not relevant to what's broken. It comes from MoveIndicatorBubble auto-adding itself to the drag layer and core Blockly now trying to auto-focus anything that does that. This logic might not be 100% correct and may need adjustments, but disabling that logic in MoveIndicatorBubble doesn't change the behavior.

The major difference I'm noticing between Firefox and Chrome is that while both have the correct focused node when move starts, Firefox changes the active element back to the body (presumably due to the element being moved to the drag layer). This is quite concerning since it likely indicates that there isn't a focus lost event being fired when the element moves. What's more concerning is that forcing focus doesn't seem to affect anything (which may imply that focus is being lost after the element moves, but I really hope that isn't the case).

Clicking on a block has the same outcome, and in fact you can very briefly see that the clicked block has an outline (and thus focus) before it is lost. This is unrelated to the drag layer and needs more investigation. I actually plan to try and fix this bit first since I suspect it may have a common root cause to the dragging issue.

[BenHenning]

ueberdosis/tiptap#3761 (comment) looks very suspiciously similar to the behavior that I'm seeing, though I'm not 100% convinced. At the moment I'm assuming that clicking on a node is causing its bring to front routine to change the DOM structure which then causes the body root to gain focus without Firefox (or Safari) firing the "focus lost" event for the FocusManager to pick up on. I can't tell if this is a spec issue or something Chrome simply does differently.

Edit: Confirming that this seems to be the root problem as disabling bringToFront fixes the clicking flow.

What's unclear is why the extra focusNode behavior in bringToFront isn't working to self-correct in this exact case (unless there's some sort of delay happening with updating focus in Firefox).

Edit 2: Ah, this is actually making perfect sense. The order of operations that's happening is essentially:

• User clicks
• Gesture handling focuses the node (this works as expected)
• Gesture brings the block to the front
• Block element is removed and re-added to DOM. Behavior diverges based on platform:
• For Chrome:
  • The removal of a focused element from the DOM sends a focus lost event
  • FocusManager clears its internal state
  • bringToFocus attempts to re-focus the previously focused node using focusNode
  • FocusManager refocuses the node since it currently holds no focus
• For Firefox/Safari (assumed):
  • bringToFocus attempts to re-focus the previously focused node using focusNode
  • FocusManager ignores the rest because it thinks a node is already focused due to no event being fired. At this stage FocusManager and the DOM focus are out of sync

I'm certain that dragging has the exact same problem due to moving elements to/from the drag layer.

I am uncertain how to fix this currently.