WordPress block has large whitespace at the bottom

[notnownikki]

Describe the bug

In the editor, inserting a WordPress block and embedding a post renders with a load of whitespace. It seems this happened because the html returned for embedding a post changed at some point.

cc @jasmussen

[jasmussen]

Confirmed. In fact it's not just any random sized space, the block is being treated as "responsive 16:9".

Editor:

Frontend:

Actually... hmmmmmmmm. I think maybe the embed block is "fine", because the bug as shown above is actually because the theme I'm testing with is providing its own responsive embed styles, which should not be there.

In your testing environment, what theme did you use and which plugins did you have enabled?

It's possible that if a regression happened, it happened in the responsive-embeds opt-in function call — maybe it opts in for all themes now even when it shouldn't? Not at all sure, but right at this point my gut tells me this isn't a Gutenberg issue.

[notnownikki]

Stock WP no plugins, 2019 theme. (Afk today, sorry for the shortness of email!)

…

On Thu, 28 Mar 2019, 08:57 Joen Asmussen, ***@***.***> wrote: Confirmed. In fact it's not just any random sized space, the block is being treated as "responsive 16:9". Editor: [image: Screenshot 2019-03-28 at 09 51 43] <https://user-images.githubusercontent.com/1204802/55143547-4261b580-513f-11e9-9cea-2418d49e5564.png> Frontend: [image: Screenshot 2019-03-28 at 09 51 49] <https://user-images.githubusercontent.com/1204802/55143551-442b7900-513f-11e9-9d4d-9f49d9f6ffe3.png> Actually... hmmmmmmmm. I think maybe the embed block is "fine", because the bug as shown above is actually because the theme I'm testing with is providing its own responsive embed styles, which should not be there. In your testing environment, what theme did you use and which plugins did you have enabled? It's possible that if a regression happened, it happened in the responsive-embeds opt-in function call — maybe it opts in for all themes now even when it shouldn't? Not at all sure, but right at this point my gut tells me this isn't a Gutenberg issue. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#14659 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADKSsrxF9uO4bdjpGO1n3SMcvk0tFPdgks5vbIPrgaJpZM4cNg4R> .

[jasmussen]

@kjellr can you recall if TwentyNineteen opts into responsive embeds? Or does it have its own embed responsiveness magic?

[kjellr]

Yes, Twenty Nineteen does opt in to responsive embeds.

[notnownikki]

When I'm back I'll check if the block does any responsive stuff. If it does it and the embed is now coming inside an iframe, it should opt out. I know the html did change for WP embeds, so it's possible that's what's going on.

…

On Thu, 28 Mar 2019, 13:04 Kjell Reigstad, ***@***.***> wrote: Yes, Twenty Nineteen does opt in to responsive embeds. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#14659 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADKSsoWVLP9MgD-NCfge0Fbrvu59ocg4ks5vbL3DgaJpZM4cNg4R> .

[notnownikki]

Checking this out, and found...

	{
		name: 'core-embed/wordpress',
		settings: {
			title: 'WordPress',
			icon: embedWordPressIcon,
			keywords: [ __( 'post' ), __( 'blog' ) ],
			responsive: false,
			description: __( 'Embed a WordPress post.' ),
		},
	},

The WordPress block does not have responsive styles applied, in the editor or the front end, and yet there's still a load of padding at the bottom. The iframe that the embed is rendered in has the padding...

That iframe is coming from oembed, and there are no responsive styles applied to the wrapping figure.

[jasmussen]

That padding is the responsive style, it's 56.something% right? That's the responsive style for a 16:9 video. Which obviously this isn't. This is freeform, so it should not have any of that. And I'm not sure where it's coming from, because that padding should only come from the 16:9 CSS classes

[swissspidy]

Worth noting that WordPress post embeds (iframes) calculate their height and pass that information to the embedding site (host) via postMessage. That way, the host can re-adjust the height. There should be no need to do anything else except setting a width of 100% for the WordPress embed iframe.

[notnownikki]

@jasmussen no, there are no responsive classes in the embedded html at all. Unless they're being applied to all iframes (which would be a horrible theme bug) then they're not applied there. Also, the dimensions shown there are the actual height and width attributes of the iframe in the html. It's not responsive styles making that size.

[swissspidy]

Worth noting that WordPress embed iframes have a minimum height of 200px. See https://github.com/WordPress/wordpress-develop/blob/2a7aedc9e08a4a3701f908ffc981ac5a476b493c/src/js/_enqueues/wp/embed.js#L62-L72

@notnownikki This might be what you are running into at the moment.

[notnownikki]

This is the HTML oembed generates:

<iframe class="wp-embedded-content" sandbox="allow-scripts" security="restricted" src="http://localhost:8888/?p=1&amp;embed=true#?secret=U0rOggtHDr" data-secret="U0rOggtHDr" width="600" height="200" title="“Hello world!” — Gutenberg Dev" frameborder="0" marginwidth="0" marginheight="0" scrolling="no"></iframe>

It's fixed height, and it's including the page as the source of the iframe, and if I remember correctly this is quite different to what used to happen. Now the iframe is a fixed height, which means shorter content going to have that white space, as the iframe does not resize.

In the editor and in the core blocks, there are no responsive styles applied. This looks like it's down to an oembed change which also meant we needed to change the WordPress HTML detection in #14658 (which needs a review ;) )

[swissspidy]

Now the iframe is a fixed height, which means shorter content going to have that white space, as the iframe does not resize.

It should resize using postMessage calls. That's what wp-embed.js is for.

[notnownikki]

Ah. It's not doing that here. For a post that simple says "hello world!" the content in the iframe is 600x132, but the containing iframe remains 600x200. So when we have an iframe that's 1000px high, it stays that high.

[swissspidy]

Can you verify whether that wp-embed.js JS file is being enqueued on your site and that the iframe has a data-secret attribute? I'll try to reproduce on my end in the meantime.

[notnownikki]

Yes, it's enqueued (the .min version) and there is a data-secret attribute in the iframe. #14659 (comment) has the HTML that appears in the post.

[jasmussen]

I can't really reproduce in master + 2019:

What am I missing?

I can reproduce in my own theme because I haven't updated it in a while, and it provides its own heavy-handed responsive styles.

Edit: I mean, there's a LITTLE bit of extra padding below the "short" embed, but nothing that looks super wrong.

[notnownikki]

I think you are seeing it there, can you inspect the iframe on the shorter embed there?, the "Learn something difficult" one? I'm pretty sure I can see the bottom whitespace when you highlight it. If the enclosing iframe is still 200px high, you've reproduced it.

[notnownikki]

I mean, there's a LITTLE bit of extra padding below the "short" embed, but nothing that looks super wrong.

Yeah, that's a symptom. The problem is when the iframe is 1000px high, it should resize, so when a post is just enough to tip it over 200px, it'll go to 1000px and you'll see the massive whitespace.

If you inspect the short embed and you see the wrapping iframe is still 200px, then it hasn't resized and that's the problem.

[jasmussen]

Yep, I see it now. There's definitely that 200px min-height that Pascal is referring to. Which would be nice to fix, but is also not horrible since it doesn't crop anything.

But I still can't reproduce the latter thing you're referring to — do you have a link to a post that results in a 1000px embed?

[notnownikki]

Only on my local machine. This is how embedding the default "Welcome to WordPress" post looks in my browser. I can't guarantee that it would render pixel-perfect identical for you though, because of different browsers, OSes, etc. and so it might not trigger the problem for you.

[notnownikki]

If I remember we had a similar issue with the resizing iframe in Gutenberg, and it was that the initial messages posted weren't caught by the resizing listener, because of $REASON (I think it was some release of Chrome which broke it?) and so we had to fire off our own message when we registered the listener.

[jasmussen]

That's interesting, I can repeat it now:

That page is from the same dev site. It smells race-condition-y, without knowing virtually ANYTHING about the embeds (so don't take my word). In this case the iframe is 338px tall. Note it looks okayish on the frontend where it's 200px tall:

Given that this is a freeform iframe where the height is actually the attribute set on the iframe, I'm not sure I can be of that much help here :(

[notnownikki]

Whew, ok, it's not just me 😁

@swissspidy if your resizing code isn't firing, it might be that it's missing the first message. We fixed it in the sandbox component by running an initial resize ourselves, because we were missing the very first resize message after we registered the listener. https://github.com/WordPress/gutenberg/blob/master/packages/components/src/sandbox/index.js#L131

[annezazu]

I can still replicate this with WordPress 6.6.1 and GB 19.1:

[jasmussen]

The issue appears to not be the responsive embeds feature anymore. In my testing, it appears more like a race condition or something the like. Specifically it appears the explicit height is set on the iframe, on the frontend only, to match a calculated height:

But that calculation must just be wrong. @ellatrix when you get a moment, can you look?