Post Comments Block: "Older Comments" and "Newer Comments" links mis-aligned

[ockham]

Description

Users that still have the now-deprecated Post Comments block in one of their templates will find that the "Older Comments" and "Newer Comments" links aren't left- and right-aligned like they should be, but stacked on top of each other.

Previously mentioned in the Loom video in #40484.

Step-by-step reproduction instructions

1. The Post Comments block is currently hidden from the inserter. You need to remove the following line (and rebuild Gutenberg) in order to show it:

   gutenberg/packages/block-library/src/post-comments/block.json

   Line 37 in 54fd3bf

   "inserter": false

2. Go to the Site Editor and edit the Single page template.
3. Insert the block named "Post Comments (deprecated)".
4. Note that the "Older Comments" and "Newer Comments" links aren't left- and right-aligned like they should be, but stacked on top of each other. (Compare this e.g. to the Post Editor, where the links show up properly aligned when the Post Comments block is inserted.)

Screenshots, screen recording, code snippet

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

[ockham]

Comparing to the Post Editor, it seems like the "Older Comments" and "Newer Comments" links have the alignleft and alignright classes assigned, respectively:

That class seems to be coming from Core's common.css: https://github.com/WordPress/wordpress-develop/blob/b27069117eb22c39d5230ceb39439f2dab82dc08/src/wp-admin/css/common.css#L92-L99

So I guess that style isn't being enqueued for the Site Editor.

[ockham]

I checked the page source of the Site Editor, and common.css is being loaded there:

<link rel='stylesheet' id='common-css'  href='http://localhost:8888/wp-admin/css/common.css?ver=6.0-beta3-53329' media='all' />

My next best guess is that it has to do with the iframing of the Site Editor (which I know very little about 😅 ).
I just noticed a recent issue, which just had a fix by @youknowriad committed. Unfortunately, it doesn't seem to fix this issue here; maybe it's because that PR was about wp_enqueue_block_style, whereas common.css is enqueued via plain old wp_enqueue_style? 🤔

cc/ @youknowriad @gziolo

[ockham]

Yeah, so this does seem to fix the issue:

diff --git a/packages/block-editor/src/components/iframe/index.js b/packages/block-editor/src/components/iframe/index.js
index 5596aa0032..435df3a821 100644
--- a/packages/block-editor/src/components/iframe/index.js
+++ b/packages/block-editor/src/components/iframe/index.js
@@ -45,7 +45,6 @@ function useStylesCompatibility() {
 			} catch ( e ) {
 				return;
 			}
-
 			const { ownerNode, cssRules } = styleSheet;
 
 			if ( ! cssRules ) {
@@ -65,6 +64,14 @@ function useStylesCompatibility() {
 				return;
 			}
 
+			let isFilenameMatch = false;
+			if ( styleSheet.href ) {
+				const url = new URL( styleSheet.href );
+				if ( url.pathname === '/wp-admin/css/common.css' ) {
+					isFilenameMatch = true;
+				}
+			}
+
 			const isMatch = Array.from( cssRules ).find(
 				( { selectorText } ) =>
 					selectorText &&
@@ -73,7 +80,7 @@ function useStylesCompatibility() {
 			);
 
 			if (
-				isMatch &&
+				( isMatch || isFilenameMatch ) &&
 				! node.ownerDocument.getElementById( ownerNode.id )
 			) {
 				// Display warning once we have a way to add style dependencies to the editor.

I'll file a PR.

[ockham]

I'll file a PR.

#40846