Click-through pattern not behaving as expected for Template Parts

[jameskoster]

Description

There is currently a small discrepancy between the selection behaviour for Template Parts and Reusable Blocks on the canvas.

Both utilise the 'overlay' and 'click-through' pattern which dictates that regardless of where you click on the block, the parent will always be selected first. Subsequent clicks are required to select children. Here's how that works for Reusable Blocks:

RB.mp4

The same is not true of Template Parts. In the video below I am able to bypass the click-through and directly select the Site Title and the Navigation block:

TP.mp4

It's interesting that clicking the site tagline block doesn't bypass the click-through, so I'm not sure if the problem is with the Template Part block, or the Site Title and Navigation blocks instead.

The issue exists in both the template editor and the site editor.

Step-by-step reproduction instructions

1. Install and activate a block theme.
2. If one doesn't exist, create a Header template part and place it in whichever template is used to render pages.
3. Ensure the Header template part includes an instance of the Site Title and Navigation blocks.
4. Edit a page in the post editor.
5. In the Template section of the Inspector, click 'Edit'.
6. Hover the Site Title or Navigation block and click
7. Notice that the Site Title or Navigation block is selected rather than the Header template part

[Addison-Stavlo]

so I'm not sure if the problem is with the Template Part block, or the Site Title and Navigation blocks instead.

If I create a reusable block with a Site Title in it, I can repro the same behavior there as well. 🤔

I can't seem to repro in either with just the navigation block as is seen in your gif.

[Addison-Stavlo]

It seems possibly related to RichText in some way.

For the SiteTitle, I notice the issue is no longer present if I change the RichText's tagName prop from a to div (not certain of the implications here, or why its an a anyways).

I can also repro the same issue by adding a Buttons/Button block with some text in it (it also uses RichText, although not any a tag):

Although there are plenty of other blocks that use RichText that don't seem to have any issue.

[Mamaduka]

I'm removing this issue from WP 5.9 project board since RC1 was released last night.

We can try and work on the fix for the next minor release.

[annezazu]

This came up as part of the twelfth call for testing for the FSE Outreach Program:

Clicking Header or any template section is somewhat difficult, as it easily selects blocks inside of it.

I've experienced this personally and have also seen this come up throughout the community as folks are trying to ensure that they are adding content to the right spaces. Since template parts update everywhere, it's key that we ensure folks have a way to do so without much friction. The current experience makes this difficult without using List View.

[jameskoster]

I would dearly love to see this issue fixed. The longer it exists in production the more folks get used to the broken experience and interpret it as the norm, which might make changing it more difficult down the road.

[talldan]

I did some debugging. From what I can tell this is related to particular blocks being used inside Template Part rather than the template part itself.

As an example, add a Site Title into a Reusable Block, and the Reusable Block also has this issue.

So what's different about a Site Title? The only thing I've been able to change to stop this from happening is the tag name used by the site title. Commenting out this line makes things behave as they should:

gutenberg/packages/block-library/src/site-title/edit/index.js

Line 54 in 4753e0e

tagName={ isLink ? 'a' : 'span' }

So I think this is happening for any inline RichText elements (since it also happens when the site title renders a span). That would square with the original report which also mentioned that clicking on the Nav block is an issue - Navigation Links are also inline Rich Text elements.

I'm still not sure of the root cause. This is the event handler being triggered that results in selection, but I don't know why it only triggers for inline Rich Texts:

gutenberg/packages/rich-text/src/component/use-input-and-selection.js

Line 254 in 4753e0e

function onFocus() {

[ndiego]

Thanks for doing some debugging @talldan. Is this a bug we think we can reasonably tackle for 6.0? Just trying to figure out what needs to remain on the 6.0 Project Board. Thanks!

[jameskoster]

This was missed for 5.9. It would be a real shame if it didn't make it into 6.0 either 😔

[talldan]

I don't think there's any reason to punt it yet, it'd be a good bug to fix, even if I still have no idea how to fix it 😄

[talldan]

The suggestion here does help - #40309 (comment). I've made a PR - #40339.

After some searching I discovered a few other people complaining that browsers don't respect pointer-events: none on inline elements (particularly links since they accept a click event), so it seems like a browser quirk. Lots of people mention using inline-block as a workaround, but that's not really an option here.

From what I can tell the above PR fixes things in most browsers, but Safari was notably still broken.

[talldan]

I've reported the Safari issue upstream - https://bugs.webkit.org/show_bug.cgi?id=239486

[talldan]

Just removing my assignment as #40339 is only a partial fix. I don't plan on continuing to work on this any more than that PR, further contributions are welcome though if that can be improved on.

edit - #40339 is now merged.

[Mamaduka]

@jameskoster, do you think we can close this now that #40649 is merged?

[jameskoster]

Yes, I think so :)