Site Editor: Full width Cover blocks that use Featured Image show a visual glitch when resizing in the preview pane

[jordesign]

Description

When a Template or Pattern uses a Full width cover block that is set to use the featured image - it shows a strange flicker in the placeholder/background when the preview panel resizes (on hover).

Step-by-step reproduction instructions

1. Open the site editor and edit/add a template.
2. Add a Cover block, set to use the Featured Image as the background.
3. Set the block to Full width.
4. Save and close the template - returning to the site editor browse/mode.
5. Hover over the preview of the template.

Screenshots, screen recording, code snippet

In a pattern - showing it only happens with full-width aligned blocks.

Screen.Recording.2023-07-05.at.3.07.33.pm.mov

In a template

Screen.Recording.2023-07-05.at.3.09.05.pm.mov

Environment info

• WordPress 6.3 beta3
• Gutenberg 16.1

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

[carolinan]

I am able to reproduce this on macOs Chrome Version 114.0.5735.198 but not in Firefox 115.0 or Safari 16.5.1 (18615.2.9.11.7)

[ndiego]

I'm struggling to reproduce this in Chrome 🤔

[jordesign]

Version 114.0.5735.133 of Chrome for me

[carolinan]

PC Windows 10, Chrome Version 114.0.5735.199, WP 6.3-beta3-56143:
Without Gutenberg: No issue
With Gutenberg Version 16.1.1: No issue
With Gutenberg trunk: No issue

It makes no difference if I try changing the browser window width or screen resolution on either the PC or Mac.

If I view a page instead of a template, I do not see the flickering.

[jordesign]

Noting this is still in place in RC1

[annezazu]

Noting this can be replicated with 6.3.1

[glendaviesnz]

Looks like there is a known issue in chrome with flickering when blur backdrop filter is applied, which is the case on the featured image placeholder. There are some options for fixing this in the attached blog post that I will take a look at.

[glendaviesnz]

@jasmussen It looks like it was the blur that was added here that causes this. I have had a look and can't see any way to stop the flicker in this context. Do you have any thoughts on alternatives to get the same UI effect without the blur?

[jasmussen]

Fascinating! Thanks for the ping.

This is why the blur was added, so that the placeholder would always be legible if placed on a background image:

Curiously I'm not able to initially reproduce the original issue reported in Chrome. In fact, I'm seeing the backdrop-filter removed from placeholders through this rule:

But if I manually check that off, I see it, sure enough:

Curiously, I also see this weird behavior in the post editor, where if you place the caret in the tittle field, the caret itself gets blurred by the backdrop filter:

Knowing that, and knowing that the frame scales on hover, it seems like the issue is the rounding math that is present when CSS transforms scale the preview frame. Shown in this GIF, how applying a border on this frame can color the blur that gets flickered in:

That also kind of explains that the issue here is primarily browser rounding math, and the fact that contents surrounding the blur filter can affect the inner contents. The net result is somewhere between "to be expected" and "oh math".

So what do we do about fixes? Beyond any browser fixes, I've found two hacks that seem to address this, neither of which are great. First one is to add a little inner padding on the frame:

.block-editor-iframe__body {
	padding: 0.7px;
}

This is sub-optimal because it definitely is intentional that the frame has no inner padding. And 0.7px seems to be the lowest we can go to avoid the blur.

The second hack is probably a bit more acceptable since it affects just the placeholder state, but it's still not great since I believe it affects all placeholder states. It's something along the lines of the following:

.wp-block-cover .wp-block-cover__image--placeholder-image {
    bottom: 0.8px;
    left: 0.8px;
    position: absolute;
    right: 0.8px;
    top: 0.8px;
    width: auto;
}

Here, we change the abs-positioning of the blurred illustration inside the placeholder to be _slightly pushed inwards from the edge of the container. This ensures that the featured image doesn't ever touch the dark background edges, and is thus not needing to blur them when they bleed in. The code needs a little sanity check, and to live in the right place, but it could potentially be a heavily CSS commented hack for the time being.

That said, I wish there was a cleaner hack to contain the re-painting inside just the placeholder illustration and in case you're a CSS wizard inspired by the above (perhaps @t-hamano?) could find a better solution. Hope that helps!

[t-hamano]

Thank you for pinging me!

I was able to reproduce this issue on my Windows machine. It can only be reproduced in Chrome, and cannot be reproduced in Firefox.

Screencast in Chrome

448c59edc5a88f2513cb13650a4b0eef.mp4

Screencast in Firefox

4706a8c4750f20f7a5435880296843d5.mp4

Here is the markup.

Details

<!-- wp:cover {"useFeaturedImage":true,"dimRatio":50,"customOverlayColor":"#FFF","isUserOverlayColor":true,"isDark":false,"layout":{"type":"constrained"}} -->
<div class="wp-block-cover is-light"><span aria-hidden="true" class="wp-block-cover__background has-background-dim" style="background-color:#FFF"></span><div class="wp-block-cover__inner-container"><!-- wp:paragraph {"align":"center","placeholder":"Write title…","fontSize":"large"} -->
<p class="has-text-align-center has-large-font-size"></p>
<!-- /wp:paragraph --></div></div>
<!-- /wp:cover -->

<!-- wp:cover {"url":"https://live.staticflickr.com/4572/38004374914_6b686d708e_b.jpg","id":1,"dimRatio":50,"customOverlayColor":"#FFF","isUserOverlayColor":true,"isDark":false,"align":"full","style":{"spacing":{"padding":{"top":"var:preset|spacing|80","bottom":"var:preset|spacing|80"}}},"layout":{"type":"constrained"}} -->
<div class="wp-block-cover alignfull is-light" style="padding-top:var(--wp--preset--spacing--80);padding-bottom:var(--wp--preset--spacing--80)"><span aria-hidden="true" class="wp-block-cover__background has-background-dim" style="background-color:#FFF"></span><img class="wp-block-cover__image-background wp-image-1" alt="" src="https://live.staticflickr.com/4572/38004374914_6b686d708e_b.jpg" data-object-fit="cover"/><div class="wp-block-cover__inner-container"><!-- wp:cover {"useFeaturedImage":true,"dimRatio":50,"customOverlayColor":"#FFF","isUserOverlayColor":true,"isDark":false,"layout":{"type":"constrained"}} -->
<div class="wp-block-cover is-light"><span aria-hidden="true" class="wp-block-cover__background has-background-dim" style="background-color:#FFF"></span><div class="wp-block-cover__inner-container"><!-- wp:paragraph {"align":"center","placeholder":"Write title…","fontSize":"large"} -->
<p class="has-text-align-center has-large-font-size"></p>
<!-- /wp:paragraph --></div></div>
<!-- /wp:cover --></div></div>
<!-- /wp:cover -->

I also tested a CSS hack solution, but it didn't work in my environment. It might also be affected by the size of the browser.

Screencast

231ef931786a6e8ac61e0b2babdb6838.mp4

Another solution might be to apply a semi-transparent white background instead of backdrop-filter. In other words, CSS like below:

.components-placeholder.has-illustration {
  background-color: rgba(255,255,255,0.5);
}

However, it will look different when placed in front of a background with colors or images.

Before	After

[jasmussen]

Thanks so much for looking.

The main problem with the semitransparent background color is that if the background is noisy enough, it affects legibility.

Can you try a larger padding than 0.7px, just to see if that fixes it for you? Mainly as a test.

[t-hamano]

Can you try a larger padding than 0.7px, just to see if that fixes it for you? Mainly as a test.

Unfortunately, the problem was not resolved in my environment.

Screencast

6992d70c0029ed3dfbf82b47bce71c1e.mp4

In addition, I have tried several of the solutions in the article linked to in this comment.

1. Optimize the backdrop filter: I tried lowering the blur value significantly, but could not eliminate the flickering completely.
2. Use hardware acceleration: In my environment, on the contrary, I was able to solve the problem by turning this setting off.

The following four would not be ideal solutions, as they would require design changes.

3. Minimize the affected area
4. Avoid nested elements with backdrop filters
5. Limit the use of backdrop filters

From this bug report, it still appears to be a Chromium issue and not yet resolved.

[jasmussen]

I created a codepen to better explain what I think is going on: https://codepen.io/joen/pen/yLGExva?editors=1100

Here's a GIF:

It's showing how when you resize until the blurred area touches the black edge, the black edge starts bleeding into the filter. This is expected. The flickering happens, I believe, when sub-pixel rendering is involved. And we are scaling up the viewport using transform: scale, so subpixel handling will be part of it. And so as this happens, as the viewport scales, then every once in a while Chrome's rounding math will switch back and forth between the black overlapping and not.

[t-hamano]

Thank you for your detailed explanation, @jasmussen.

In other words, does this mean that this problem may be solved with CSS that has some kind of decimal point value? Sorry if I didn't understand your intentions correctly.

[jasmussen]

No, what I mean is that all browsers have some rounding math they do, when calculating a subpixel. Let's say I have a 400px wide div with a blue background. Then I apply a transform: translateX(0.4px);. This affects some of the antialiasing of the box. But then if the box is horizontally centered on a 2x resolution screen, that antialiasing will further be nuanced, for every single pixel the window is resized. In some cases it will have to round down, in other cases it will have to round up.

The issue at play is that if this box is set to blur the background, the surroundings sometimes bleed in. This isn't entirely incorrect behavior. It just makes it tricky to cleanly and firmly say that this is a bug in Chrome, which means that it might not ever be fixed on the browser end. I would think that overflow should prevent things from bleeding in, but that's the kind of CSS fixing we might need here.

[t-hamano]

Thank you for your detailed explanation.

I've tried several approaches, including using will-change:transform; and overflowing the element with blur applied, but I haven't found a solution yet.

By the way, I found a report similar to this issue, so I'll leave it here.

• Backdrop-filter blur not resizing when changing window size - Stack Overflow
• Flickering backdrop filter blur on scaling - Stack Overflow

[jasmussen]

Great links, that echoes our conversations. It does suggest it's a chromium bug:

Though i still maintain that it isn't entirely clear that it's a bug, because of the nature of how blur should be affected by its surroundings. Here's a simple example in Photoshop of how the blur in the middle of looks like a straight left to right gradient:

This happens because the black square on the left extends all the way from the top to the bottom, therefore the blur in the center can be aware of information above and below.

If the above and below were white, on the other hand, as would the blur be different:

This is because now there's white information above and below affecting the blur in the middle. This is despite the square in the center not touching the surroundings at all.

That said, if I cropped the canvas to just the square, before the blur, then there would not exist any "outside information" above and below, and we would again get a perfect gradient:

My main point in illustrating this is, it isn't clear cut whether it's a bug or feature, and for that reason, I don't think Chrome will be making changes anytime soon. Which is mainly an argument that we need an alternative. And just like I suggested, the solution likely means we need clearance around the blurred box, whether through a border or padding, as suggested also here:

I tried to go as low as possible, 0.7, but that may not be enough. I'll try a quick PR.

[jasmussen]

Just checking in: is this still an issue? My instinct is yes, but wondering if anyone has updates.

[t-hamano]

In the latest version of Gutenberg, there seems to be no animation when hovering over the canvas. Does anyone know if this is an intentional change or a regression?

Personally, I prefer the latest version without animations.

a08894418e1e1f860a7ad71d7cdf70a4.mp4

[jasmussen]

@youknowriad do you know? I think you worked on animation recently☝️

[jasmussen]

It seems unintentional.

[youknowriad]

Yes, I guess one of my refactorings removed the animation, I'm also not sure that the animation adds too much value though.

[t-hamano]

How about displaying an outline instead of zooming in on mouse hover? This matches the style when focusing the canvas with the keyboard.

Related PR: #50296

0cec2cdb5606b511b02e65bc4822a24e.mp4

[jasmussen]

I'm also not sure that the animation adds too much value though.

It feels important to suggest interactivity when clicking on it. As part of the details normalization work, I'd think that's even more important to keep, IMO. But the animation already needed a little work — previously what triggered it was the entire real-estate on the right, as opposed to just the frame itself, which meant that even if you had scaled down the preview to a mobile phone size, just hovering any part of the right side of the screen would trigger the behavior.

[jasmussen]

I've a tentative flicker fix for the bug that was caused by the resizing in #61201. That of course assumes we'll restore the scaling (which I think we should), and that the way we restore it causes that visual glitch to reapper.

[t-hamano]

I checked #61201, but another concern with restoring scaling is that text becomes blurry when hovered. Does this occur in your environment?

The video below was tested with WP6.5 with scaling enabled. You can see more details by viewing the video in full screen.

cd9e15029039e9a52a0685ebee72fe5d.mp4

[jasmussen]

That does not occur in my env, no. 🤔

[t-hamano]

but another concern with restoring scaling is that text becomes blurry when hovered.

Is there anyone who can reproduce this problem? You should be able to test it with WordPress6.5.

However, the scaling itself has existed before, so it might be okay to bring it back.

[annezazu]

@jordesign can you replicate this still? I wasn't able to replicate in Chrome, 6.5.2, with GB 18.2 installed.

[jordesign]

I'm still seeing it in WP 6.5.2 without GB active. But once GB 18.2 is active I confirm I don't see this any more (as the scaling/animation doesn't happen).

[jasmussen]

As it turns out, the issue is temporarily fixed due to a regression in trunk. That regression is that the preview pane no longer scales up on mouseover. But this is a scaling that we will likely restore, as it serves a purpose to indicate interactivity. That said, I have a new PR prepped in #61201, that should fix the glitching once the scaling is restored.

[t-hamano]

#61647 restored the zoom effect, but for some reason, I can no longer reproduce this problem in my environment (See this video). That PR is included in the recently released Gutenberg plugin version 18.4.

Is there anyone who can still reproduce this problem?

[jasmussen]

I can also not repro, so tentatively I'm going to close this one. Let's reopen if it it re-emerges.