Wp-calypso: Manage Reusable Blocks Link Fails in Calypso. New Tab Opens in Calypso-ify.

[scosgro]

Steps to reproduce

1. Starting at WordPress.com Simple Site
2. Create a post and add a Reusable Block to that post. Publish.
3. Create a new post, go to add a Reusable Block. Click on "Manage all reusable blocks"
4. The link will refuse to connect.
5. Opening Manage all reusable blocks in a new tab opens it in Calypso-ify.

What I expected

The link to work.

What happened instead

The link only works if you open it in a new tab.

Browser / OS version

Chrome, Firefox, appears to be all.

Screenshot / Video

https://cloudup.com/ct_GtnKoUwH

Context / Source

#painpoint #manual-testing

Found while investigating https://github.com/Automattic/wp-calypso/issues/38929

[damiannep]

Reported in 18239338-hc

[mrfoxtalbot]

I just noticed this same issue on my own and found this open issue. Here is the recording:
https://d.pr/v/oOdq4K

This issue will not happen when using wp-admin, it will redirect correctly to
wp-admin/edit.php?post_type=wp_block

While we are on this, I think that we should consider adding a direct link to manage Reusable Blocks in /wp-admin under Settings, but this is a different matter.

[mrfoxtalbot]

Oddly enough, if we access it via the "Caterpillar" menu it will work fine:

It will take me to the Manage Block section in Calypso:

[xpurichan]

I found this troubleshooting another reusable block bug. I tested in Safari and Chrome. In Safari nothing happens when the link is clicked. In Chrome I get an error page:

Both provide the same console error:
[Error] Refused to display 'https://DOMAIN.com/wp-admin/edit.php?post_type=wp_block' in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN'.

[kriskarkoski]

This looks to have been fixed, possibly from the core merge? @scosgro Can you confirm if it's fixed for you too and close if so.

[scosgro]

This looks to have been fixed, possibly from the core merge? @scosgro Can you confirm if it's fixed for you too and close if so.

This is still broken on my end. Same as the original report.

[kriskarkoski]

Yep, I can reproduce again now both on Edge-stickered and current versions of the Block Editor in Calypso. Thanks for checking!

[lancewillett]

This is a case where Calypso loads the Gutenberg block editor in an iframe with a different "origin", meaning any actions that take you away from the iframe might fail due to cross-origin security features in the browser.

Original issue with more background: https://github.com/Automattic/wp-calypso/issues/30551

There are two ways to tackle cases like this:

1. Override the cross-frame blocking by adding a frame_nonce query to outgoing link — on the backend, we have a plugin that allows cross-origin frame navigation if that one-time token is present in the request URL.
2. Build the feature into Calypso so that there is no need to navigate away.

[lancewillett]

Adding to the Create team's backlog for fixing as part of an upcoming maintenance rotation.

[ChrissiePollock]

Also reported on #2896979-zen

[xpurichan]

Received a report in 20826237-zen

[fashuvo]

Another report in #2999041-zen

[chrisfromthelc]

I have a user experiencing this in #19433510-hc

[thabotswana]

Another report in #3054127-zen

[Addison-Stavlo]

It looks like this link (as well as the one in the caterpillar menu) were handled for calypso over a year ago. The link in the inserter broke due to a css class name changing when the inserter was moved to a different package in core Gutenberg. #43782 updates that and fixes this issue, however it is a bit of a shame this link was broken for 6 months due to a class name needing updated. 🤔 We definitely need a better way to manage these type of fragile fixes that depend on css selectors.