Focus the default block after it gets added at the end of the canvas

[afercia]

Description

When clicking the empty area at the end of the canvas, the default block (a paragraph) gets added. However, the new added block is not selected. As such, it doesn't get focus. As a user, to start using the new block or the 'slash inserter' I have to click again the editable part of the new block. Animated GIF to illustrate:

I'm not sure whether there are reasons to not select and move focus the default block but the current behavior seems inefficient to me and there's room to improve usability and accessibility. As an user, I don't want to click twice. I just want to click and start typing.

I may be missing something but if there are no side effects on other flows, keyboard operability and such, I'd say that one click less would be a quick win to provide some better user experience.

Step-by-step reproduction instructions

• Create a post.
• Add a block e.g. a Group.
• Using a pointing device, click the area below the Group block.
• Observe the default block is added into the canvas.
• Observe the default block is not selected.
• Observe the default block editable content is not focused.
• Observe you have to click again the block to select it and be able to start writing or using the slash inserter.

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

[stokesman]

Thanks for opening the issue. I was about to report on the same thing. However, in my experience this only happens when the editor iframe is not present. Can you confirm? I.e. it does work if the canvas is in the iframe.

[stokesman]

Also, to include a bit of info that I was going to put in the issue I started, I tried debugging this but didn’t figure it out. I'm pretty sure it has nothing to do with any of writing flow behaviors as I went through and tested any that seemed potentially conflicting. One stupid thing I tried that resulted in this working (at least in a non-iframe context) was:

diff --git a/packages/block-editor/src/components/block-list/use-block-props/use-focus-first-element.js b/packages/block-editor/src/components/block-list/use-block-props/use-focus-first-element.js
index 27f72d1a10..c5cab7c2d7 100644
--- a/packages/block-editor/src/components/block-list/use-block-props/use-focus-first-element.js
+++ b/packages/block-editor/src/components/block-list/use-block-props/use-focus-first-element.js
@@ -85,7 +85,7 @@ export function useFocusFirstElement( { clientId, initialPosition } ) {
 				return;
 			}
 		}
-		placeCaretAtHorizontalEdge( target, isReverse );
+		// placeCaretAtHorizontalEdge( target, isReverse );
 	}, [ initialPosition, clientId ] );
 
 	return ref;

[afercia]

Thanks for opening the issue. I was about to report on the same thing. However, in my experience this only happens when the editor iframe is not present. Can you confirm?

@stokesman thanks for looking into this. For me, this happens with the editor iframed as well.

• Gutenberg trunk
• Twenty Twenty-Five
• No metaboxes (but anyways after Split content view with open metaboxes #64351 the editor is always iframed)

GIF to illustrate:

[stokesman]

Thanks Andrea 🙇, I hadn’t been seeing it in the iframed editor because when I noticed it I was on an older branch and forgot to check latest trunk.

git bisect pointed me to d9551aa as the commit that regressed it. I’m still in the dark as to why.

[stokesman]

Still pretty stumped on this but from testing it was working in 6.6.1 and broken in 6.6.2. It is currently broken in 6.7 beta. I'm not sure if that qualifies it for fixing it in 6.7 at this phase of the release cycle.

[t-hamano]

I have confirmed this issue.

6.6.1 correctly focuses the last block, but 6.6.2, 6.7 Beta1, confirmed that it doesn't work properly. d9551aa is a revert commit, so I'm wondering why the issue reoccurred in this commit. Maybe d9551aa unintentionally fixed the focus issue 🤔

[stokesman]

Maybe d9551aa unintentionally fixed the focus issue

I take it you mean the changes reverted by that commit had been a fix. It’s what I thought too. To test, I checked out the reverted commit’s parent 609a3c8 and found focus worked there. Because of that (and the fact that focus was never actually handled by the padding appender hook) it makes me suspect that the revert wasn’t a perfect reversal. I could be missing something though.

Aki, do you have a clear idea about possibility of getting this fixed for 6.7? I wasn’t sure if it qualifies due to it having not been introduced by 6.7. I would nice to, but if not, I guess it can be in a minor release.

[stokesman]

I think I’ve figured this out but it’s EOD for me so I’ll finish confirming it tomorrow and see about a PR then.