Image block captions disappear offscreen when mousing over resize handles (in Safari)

[kjellr]

When an image has been resized, mousing over the resize handles (both horizontal or vertical) causes the caption to gradually move downward with each time your mouse passes over the handles. Happens only in Safari.

To reproduce:

1. Using Safari, start a new post.
2. Insert an image with a caption.
3. Manually resize the image using the handles. This should work fine.
4. Once the image has been resized, mouse over the handles again.
5. Observe that the caption starts to disappear off the bottom of your screen.

GIF:

Tested on:

MacOS 10.14.5
Safari 12.1.1
Gutenberg 5.8.0

[melchoyce]

I'm able to replicate this very strange bug 😂

[kjellr]

Thanks for confirming, Mel.

cc @marekhrabe, in case you have any idea what's happening here. 😄

[talldan]

Oh wow. I did some trial and error toggling of styles in the dev tools.

Removing these styles seems to resolve the issue:

gutenberg/packages/block-library/src/image/editor.scss

Lines 123 to 124 in fc2835e

	display: table-caption;
	caption-side: bottom;

Not entirely sure what they do.

[p3ob7o]

I can also reproduce on Safari 13.0 (15608.1.27.40.1), macOS 10.15 Beta (19A487l)

[youknowriad]

@jasmussen Can we remove these styles highlighted by @talldan? They were introduced by #7721 and I know floats can be tricky :)

[jasmussen]

Hmm, this is tricky. The table rules are there to ensure that a floated non-resized image with a HUGE caption actually has its caption limited by the boundary of its container. The table property makes that happen.

But it is kind of hacky, I do agree. I will take a look when I can, to see how to reproduce/fix this in a way that doesn't regress floated images with captions.

[jasmussen]

So, here are visuals that explain why the block is display: table;

Without it, a long caption is wider than the figure element. This is the same issue in the editor.

HOWEVER, since this issue is editor only, we can potentially change the markup or CSS used to style the caption in the editor, so the issue is worked around. However this takes the two files out of sync, which isn't great.

I would rather we keep exploring other solutions, because the floats + images + captions is a very very difficult challenge.

[MarieComet]

Hi,
The bug still exists on WordPress 5.3 and Safari 13.0.3.

[crobertwatson]

I saw this happening on a friend's WordPress site as well. Part of it may be due to the new HEIC image format on iOS devices. It happens with those when he tries to upload them but not with JPG files. Might be due to HEIC not being supported in WP?

[jomurgel]

I feel like this is definitely a display: table-caption bug with Safari. I've had similar "jumping" issues with table CSS in Safari. Unfortunately, I'm unable to find a fix for this without either restructuring the HTML or setting max widths on containers.

Still present in WP 5.3.2 and Safari 13.0.5

[matthewmcvickar]

This is still present in WordPress 5.4.2 + Gutenberg 8.7.0 + Safari 13.1.2.

Adding a max-width to the containing <figure> works to fix this. (It makes the display: table on <figure> and the display: table-caption on <figcaption> unnecessary, thereby not triggering the visual glitch.)

Note that the the max-width on the <figure> element will have to be updated live as the image is resized, but since the <div> containing the image is already updating its dimensions on the fly, this is doable too, right?

I think setting a max-width on the containing<div> is considerably less of a hack: There's no way in CSS to indicate that a certain element inside a floating container should be the one that sets the max-width of that container.

There’s a problem with this approach if it can't be editor-only: the output HTML would force theme authors to override inline CSS of max-width on <figure> with an !important if they wanted to change the style (e.g., making floated images full-width on smaller screens).

@jasmussen Thoughts?

[jasmussen]

Note that the the max-width on the

element will have to be updated live as the image is resized, but since the

containing the image is already updating its dimensions on the fly, this is doable too, right?'

That is doable, yes, but it seems like an elaborate hack to what is essentially a Safari bug.

That's not to say it shouldn't be addressed, it absolutely should, but just that it'd be nice to consider the above approach a "plan B" and seek a better plan A first. Can I ask you test the issue in Safari Technology Preview? Ideally we would also get someone to test in Safari 14, which is part of the next MacOS update. It'd be nice if the bug was solved there.

I'll put on my todo list to test this myself, but I have a bit on my plate for the impending 5.5 release.

[matthewmcvickar]

I don't have the next macOS update beta, but did download Safari Technology Preview version 14.0 in macOS Mojave 10.14.6, and the bug persists:

[jasmussen]

Thank you for the followup. I will take a look again and see if I can find a workaround.

[jasmussen]

I created a fix in #24540.

[matthewmcvickar]

Wonderful, thank you for researching and implementing this workaround. :)