Non-typable areas of paragraph and insertion blocks on selection

[tomjn]

Describe the bug

It's easy to click areas of a paragraph or inserter block, such that they are selected, but no typing is possible

To Reproduce
Steps to reproduce the behavior:

1. Click on a large region of a paragraph or inserter block where the cursor changes from a text insert to a pointer
2. Attempt to type

Expected behavior

I expected what I typed to appear inside the block. It did not

Screenshots

https://youtu.be/mOowQS-yWXo

When a block is in this state, it is selected, but nothing can be done with it, and it's not clear that that's the case, or how to gain focus:

Additionally, the area that can be clicked on that selects but does not focus the text is rather large and easy to miss-click on

Desktop (please complete the following information):

• OS: macOS
• Browser chrome
• Version 69

Additional context

• 4.0 RC1

Related to #8541 which focused on just the drag handler, but this is a more general issue than that, and can be demonstrated without the drag handler

[tomjn]

As an aside, I don't believe there should be any functional difference between having a block focused, and having a singular block selected. Typing when a single block is selected should have a similar effect to appending to the end imo

[chrisvanpatten]

Is there a chance this is also related to #10090? That focuses on hovering, but I think the same would apply for clicks.

[tomjn]

Somewhat, that helps define the area you can click on to trigger this issue. This would still be an issue with the new block inserter though, as the typable area doesn't span the full width, there'd still be regions surrounding the icons on the far right

[designsimply]

Tested and confirmed the behavior using WordPress 4.9.8 and Gutenberg 4.0, however, it does also make sense to me that I have to click on the content itself before I can edit it (not just click to select the block).

When a block is in this state, it is selected, but nothing can be done with it

Nothing can be done with typing, but in this state you can interact with the sidebar and toolbar and block movers.

[youknowriad]

I've been thinking about this lately. I know @aduth had thoughts as well. The problem here is that this space is not part of the block, it's actual margin between blocks and it can even be tweaked by theme authors. Also some blocks might not having a typing area at all.

It's not clear to me what's the actionable item here or if we should just consider this as "works as intended".

[aduth]

There's definitely overlap between this and #18733.

I think this one touches on another point, which is that every block will have a focusable wrapper, including those we'd otherwise already expect to be focusable by the fact that their primary interaction is some form of input (e.g. a paragraph's contenteditable). This wrapper exists largely to support focus on blocks which do not have anything natively focusable (like the image block). But we don't really want this to ever become the active element for something like the paragraph block.

As action items, I could see it as fixing whatever it is that allows the paragraph to become focused. This could either mean (a) something like #18733 where I talk about replacing margin with padding (so there's never a region of the block you could focus other than the input itself), or (b) forcibly moving the focus to the inner input when focus lands on the block wrapper and the block is already otherwise capable of handling the focus.

This could even be something where the block opts out of the focusable wrapper. I believe this is what @ellatrix is proposing in #19701 :

For blocks that opt in, it will get rid of the useless focusable wrapper element. For example, a paragraph block has currently two focusable elements: the wrapper and the paragraph. The focusable wrapper is useless here, and adds an extra tab stop. There's no reason for the paragraph not to be the wrapper.