Using a File Block with a PDF makes the editor crash in Safari

[liviopv]

Steps to reproduce the behavior

1. Add the File Block to a new post or page
2. Upload or select a PDF in the File Block
3. Open the post/page editor in Safari.

What I expected to happen

What actually happened

In Chrome/Firefox, the editor will render the PDF as an embed (which sounds not ideal, IMO). In Safari, the editor will not load and show a blank page.

Chrome:

Screenshot: https://d.pr/i/S27E3C

Safari - the editor freezes completely, likely trying to render the PDF as an embed

Screenshot: https://d.pr/i/yWxmXk

Context

Seems to be related to #52743

Browser / OS version

Safari 14.1

Is this specific to the applied theme? Which one?

No

Does this happen on simple or atomic sites or both?

Only tested Simple Sites

Is there any console output or error text?

I can't get the console errors from Safari, but here are the ones from Chrome:

??-eJylkkFuxCAMRS9U4tCqo2yqnoVgT+IUMAKTaXv6supiNq2GDZKF37Nlfbhl4yUpJYUc2sapwtZ6uVLZzC17ife1cZmvpH6fjvoE/+B9Iadk+uvV+OBqnSKnv2kvheC087RMM6yNA4JrKhk4IX0+xK9B1jHcf5hKhV3gb6csySBdXQtqsiv9Y0C+awymd7My1QFPLhy74xyS1F2KekEavdbIEtjD1lODXwMOZ+0dzsmHhv06RwXkqnBSQikQJXbrw9HEnvHfQe/xzV6eX+yyXObX4wdXtDvR:264 Block validation: Block validation failed for `jetpack/subscriptions` (Object).

Content generated by `save` function:

<div class="wp-block-jetpack-subscriptions wp-block-jetpack-subscriptions__supports-newline">
			[jetpack_subscription_form
				subscribe_placeholder="Enter your email address"
				show_subscribers_total="false"
				button_on_newline="false"
				submit_button_text="Sign up"
				custom_background_emailfield_color="undefined"
				custom_background_button_color="undefined"
				custom_text_button_color="undefined"
				custom_font_size="16"
				custom_border_radius="50"
				custom_border_weight="1"
				custom_border_color="undefined"
				custom_padding="17"
				custom_spacing="8"
				submit_button_classes=""
				email_field_classes=""
				show_only_email_and_button="true"
			]</div>

Content retrieved from post body:

<div class="wp-block-jetpack-subscriptions wp-block-jetpack-subscriptions__supports-newline">[jetpack_subscription_form show_subscribers_total="false" button_on_newline="false" submit_button_text="Sign up" custom_font_size="16px" custom_border_radius="50" custom_border_weight="1" custom_padding="17" custom_spacing="8" submit_button_classes="has-16-px-font-size" email_field_classes="has-16-px-font-size" show_only_email_and_button="true"]</div>
(anonymous) @ ??-eJylkkFuxCAMRS9U4tCqo2yqnoVgT+IUMAKTaXv6supiNq2GDZKF37Nlfbhl4yUpJYUc2sapwtZ6uVLZzC17ife1cZmvpH6fjvoE/+B9Iadk+uvV+OBqnSKnv2kvheC087RMM6yNA4JrKhk4IX0+xK9B1jHcf5hKhV3gb6csySBdXQtqsiv9Y0C+awymd7My1QFPLhy74xyS1F2KekEavdbIEtjD1lODXwMOZ+0dzsmHhv06RwXkqnBSQikQJXbrw9HEnvHfQe/xzV6eX+yyXObX4wdXtDvR:264

Level of impact (Does it block purchases? Does it affect more than just one site?)

Low

Reproducibility (Consistent, Intermittent) Leave empty for consistent.

Screenshot / Video: If applicable, add screenshots to help explain your problem.

[mrfoxtalbot]

Ok so this one is weird. I did a few tests on an .org site and concluded that:

1. With the plugin (10.8) active, the file block renders the PDF preview just fine.

2. As soon as the plugin is daactivated and the post is reloaded, it causes a block error in Chrome and a blank screen with a subsequent browser crash (in Safari).

I noticed this error in the console (in Chrome, since Safari crashes):

Block validation: Expected tag name `a`, instead saw `object`.

I found a couple of related core issues, but I am not 100% sure they are related.
WordPress/gutenberg#21718
WordPress/gutenberg#23510

[mrfoxtalbot]

Ok, so I have reported this here since it seems to be coming from core.
WordPress/gutenberg#32673

The difference seems to be that in WordPress.com the bug causes Safari to break, specifically.

But this is rather strange, because it is happening the exact opposite:

• WordPress.com >> The browser will crash WITH the plugin (Gutenberg plugin active by default).
• WordPress.org >> The block will break if the plugin is INACTIVE (the exact opposite).

[taggon]

@mrfoxtalbot Apparently, this is expected behavior, isn't it? :)

[mrfoxtalbot]

Thank you for checking, @taggon! The part about the block breaking if the plugin is deactivated IS expected, but:

• This should not cause the browser (Safari) to crash.
• On WordPress.com simple sites, the last version of the plugin IS supposed to be active, so I am not sure why the block is crashing when the editor is reloaded, at all.

Would this make sense? Do you think we could look into why the block is not loading in simple sites and why it is causing Safari to crash completely (as opposed to just showing a broken/unavailable block)?. Thank you!

[goblinartificer]

another incident of this today in 30641635-hc

[taggon]

I confirmed this issue still happens in Safari only on simple sites. The block editor in Atomic sites and self-hosted sites doesn't have the problem. Given that where the problem occurs, I assume that this issue is related to dotcom version Gutenberg. Unfortunately, I don't have expertise in Gutenberg. So I unassign myself from this issue hoping a Gutenberg expert will chime in.

[KokkieH]

Another report in https://wordpress.com/forums/topic/edit-screen-blank/?view=all, and I've confirmed an a test site it still happens.

Current Safari version 15.0

[jartes]

Another report on 4626133-zen

Tested on that site with Safari Version 15.1 (17612.2.9.1.20).

This is the error that I'm getting (I've masked the site and file URLs):

Block validation: Block validation failed for `core/file` (
{name: "core/file", icon: Object, keywords: ["document", "pdf", "download"], attributes: Object, providesContext: {}, …}
).

Content generated by `save` function:

<div class="wp-block-file"><object class="wp-block-file__embed" data="https://example.files.wordpress.com/2021/12/pdf-example.pdf" type="application/pdf" style="width:100%;height:415px" aria-label="Embed of     EXAMPLE PDF    <br&gt;."></object><a id="wp-block-file--media-dc34203a-168e-4736-b44e-c2ac690d8618" href="https://example.files.wordpress.com/2021/12/pdf-example.pdf">    EXAMPLE PDF    <br></a><a href="https://example.files.wordpress.com/2021/12/pdf-example.pdf" class="wp-block-file__button" download aria-describedby="wp-block-file--media-dc34203a-168e-4736-b44e-c2ac690d8618">Download</a></div>

Content retrieved from post body:

<div class="wp-block-file">&lt;object class=&quot;wp-block-file__embed&quot; data=&quot;https://example.files.wordpress.com/2021/12/pdf-example.pdf&quot; type=&quot;application/pdf&quot; style=&quot;width:100%;height:415px&quot; aria-label=&quot;Embed of     EXAMPLE PDF    <br><a id="wp-block-file--media-dc34203a-168e-4736-b44e-c2ac690d8618" href="https://example.files.wordpress.com/2021/12/pdf-example.pdf">    EXAMPLE PDF    <br></a><a href="https://example.files.wordpress.com/2021/12/pdf-example.pdf" class="wp-block-file__button" download aria-describedby="wp-block-file--media-dc34203a-168e-4736-b44e-c2ac690d8618">Download</a></div>

[KirkwallDay]

Another instance here: 33646033-hc I confirmed on a test site as well.
Users browser info: https://www.whatismybrowser.com/w/CT653AS

[jerrysarcastic]

Another report in https://wordpress.com/forums/topic/i-cant-change-one-page-of-my-website and I can confirm that I have the same issue if I try to edit a page with a PDF embed in Safari.

Safari 15.2 on Mac OS 10.15

[cuemarie]

I believe I encountered close to this issue today, here: 33855257-hc

Safari didn't crash, but this user in Safari couldn't open either of their 2 posts that contained PDFs. The PDF settings defaulted to Show inline embed, and when I disabled this for them, they could get back into the posts.

With the latest updates to the PDF embed (not showing inline embed on front end sites anyway), I wonder if this setting can be removed/hidden from the block altogether.

[levinro]

I believe I encountered close to this issue today, here: 33855257-hc

Safari didn't crash, but this user in Safari couldn't open either of their 2 posts that contained PDFs. The PDF settings defaulted to Show inline embed, and when I disabled this for them, they could get back into the posts.

With the latest updates to the PDF embed (not showing inline embed on front end sites anyway), I wonder if this setting can be removed/hidden from the block altogether.

I just found exactly what you mentioned here as well. This occurs in Safari only, all other browsers are fine. The Safari developer console showed no errors, the page just fails to load. I turned off the PDF preview so that the file is download only and then the page loads fine in Safari.

[KirkwallDay]

I can't seem to reproduce this anymore. I'm wondering if the fix issued here: #52728 affected this one. Will leave this open for now in case someone else can, but I think it can be closed.

[youbrokesomething]

This hasn't had any new user reports so I'm going to close it. Feel free to reopen if someone experiences this issue again.

[github-actions]

Support References

This comment is automatically generated. Please do not edit it.

• 4626133-zen