FormFileUpload: Prevent HEIC and HEIF files from always being uploaded on Safari

[cbravobernal]

What?

One fix could be reverting this commit c5921d7.

Adding this compatibility is causing the bug reported in https://core.trac.wordpress.org/ticket/62447

The bug reports that uploading a transparent PNG by using the upload button on a Safari browser is renaming the filename and removing the transparent background.

We can make it conditional for non Safari browsers only.

Testing Instructions

Image:

In Chrome or Firefox, create a group, set a background color, upload a block image and use the upload button to upload you're transparent PNG. Check on the frontend that the image uploaded is a transparent PNG.

Do the same in Safari. Check on the frontend that the image uploaded is a transparent PNG.

Screenshots or screencast

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: cbravobernal <cbravobernal@git.wordpress.org>
Co-authored-by: mirka <0mirka00@git.wordpress.org>
Co-authored-by: azaozz <azaozz@git.wordpress.org>
Co-authored-by: desrosj <desrosj@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: jsnajdr <jsnajdr@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[cbravobernal]

If I do a similar thing to get Safari like in duotone.js.

const isSafari =
	window?.navigator.userAgent &&
	window.navigator.userAgent.includes( 'Safari' ) &&
	! window.navigator.userAgent.includes( 'Chrome' ) &&
	! window.navigator.userAgent.includes( 'Chromium' );

eslint alerts: Use of DOM global 'window' is forbidden in module scope.

Also, checking the userAgent with a variable will trigger:
Use of DOM global 'navigator' is forbidden in the render-cycle of a React FC, consider moving this inside useEffect().

I'm not really convinced this is a good fix.
Pinging @WordPress/gutenberg-components for a quality check 😅

[mirka]

This seems to me like a reasonable and unavoidable bandaid fix in this case 👍

[azaozz]

May be wrong but moving the const isSafari = ... to the top of the file (after the imports) won't trigger the error? If not, there seems to be a function isSafari() in the build, imported from @ariakit? Not sure if/how that can be used though.

[mirka]

The point of executing that in a useEffect is so we don't break SSR use cases.

there seems to be a function isSafari() in the build, imported from https://github.com/ariakit?

Good find! But that isn't really a public API and the underlying detection mechanisms seem similar anyway. We can always encapsulate it ourselves for reuse if we need this kind of browser detection more.

[azaozz]

Right, browser detection from userAgent is generally not recommended. This seems to be the second place it's needed though, after duotone.js. This may be pretty short-lived considering one of the causes for it is already fixed in Chromium and is in Chrome Canary. Seems WP 6.7.1 may end up with reverting this fix completely.

[Mamaduka]

The point of executing that in a useEffect is so we don't break SSR use cases.

Seems like a weird hack for SSR :( Btw, using lazy initialization for state silences the warnings.

const [ isSafari ] = useState( () =>
	/^((?!chrome|android).)*safari/i.test( navigator?.userAgent )
);

[jsnajdr]

The goal here is to reference window or navigator in a safe way, so that it doesn't crash when run in Node.js which doesn't have these globals.

The ssr-friendly ESLint plugin is not perfect and it both accepts code that is bad and rejects code that is good.

This is OK but ssr-friendly will complain:

const isSafari = typeof window !== 'undefined' ? window.navigator.userAgent.includes(...) : false;

And this @Mamaduka's suggestion will crash because the useState initializer is called during SSR. ssr-friendly just doesn't detect it:

const [ isSafari ] = useState( () => window.navigator.userAgent.includes(...) );

Be careful that this will also crash in Node.js despite the optional chaining:

window?.navigator

Because the window global doesn't exist, the code will crash even before getting to apply the ?. operator. That's why the typeof window check is done, because typeof can deal with undefined variables.

One of good solutions is also using globalThis:

globalThis.window?.navigator.userAgent
globalThis.navigator?.userAgent

The globalThis variable is always present, and in browsers it has the window and navigator fields, in Node.js it doesn't have them. The ?. operator works here because we're now dealing with fields of an object, not with global variables.

I think we shouldn't need useEffect here. The UA check can be done in one pass, the component doesn't need to be rendered twice.

So, all you need is to find a solution that:

1. Actually works and doesn't crash, even if ssr-friendly doesn't warn you
2. Satisfies the ssr-friendly rules. You might need to reshuffle code that is already good, e.g., by wrapping it in a function etc.

[cbravobernal]

Thanks @jsnajdr !

I updated with the globalThis approach in 21a1cb0

Can I get a green check?

[mirka]

This is the changelog for the components package, so we need to describe the change in terms of the FormFileUpload component, not for whatever Gutenberg feature it's fixing. Something like this maybe?

Suggested change

	- `FormFileUpload`: Image Block: Fix transparent pngs not being uploaded correctly on Safari browser. ([67139](https://github.com/WordPress/gutenberg/pull/67139)).
	- `FormFileUpload`: Prevent HEIC and HEIF files from being uploaded on Safari ([67139](https://github.com/WordPress/gutenberg/pull/67139)).

[cbravobernal]

Updated in 21a1cb0

[desrosj]

I'm not familiar enough with these parts to review the code actual code changes, but this is testing well for me.

In both Safari and Chrome, I'm able to upload JPGs and HEIC images by both dragging and dropping and using the Upload option to select the files. The accept attribute is correctly reflecting the expected value for each browser.

[mirka]

Thank you for the fix!

Just as a note for similar checks in the future though — although this works in this particular case, we need to be careful that we don't assume that the existence of globalThis.navigator implies that we are in a browser context, or that the APIs are the same as a browser. Node v21 adds a partial implementation of window.navigator to globalThis.

[mirka]

You know what, if I look closely at the Node docs, there is a small range of versions where navigator exists (>= v21.0.0) but navigator.userAgent doesn't (< v21.1.0) 😂 So maybe optional chain that, too. This kind of edge case may already be a reason to prefer approaches that are safer in the general case (e.g. useEffect or globalThis.window?.navigator).

[cbravobernal]

Updated in 460ece4

[cbravobernal]

Cherry-picked to wp/6.7 for a minor release.