Error enabling "Custom fields" panel in post editor preferences

[ironprogrammer]

What happened?

In the post editor (not site editor), if you try to enable the custom fields display panel (via [Kebab Menu] > Preferences > Panels > Additional), the editor doesn't reload and appears as if the setting did not persist. Manually reloading the page or navigating away and back shows that the setting was retained.

What was expected?

Applying the setting should reload the editor automatically, and then the custom fields area should be visible.

Steps to Reproduce

1. Open a new or existing post.
2. Open the "Kebab Menu" (three vertical dots) in the upper-right corner of the page, and select Preferences.
3. Click the Panels tab and locate the "Custom fields" toggle.
4. Toggle it on and click the "Show & Reload Page" button.
5. Observe that the button shows progress, but appears to hang.
6. Navigate away and back to the page, OR click in the Playground address bar (not the browser address bar!) and press Return to reload the editor.
7. Observe that the custom fields panel is now visible in the editor.
8. Unapplying the setting also requires manually reloading as indicated in Step 6.

Additional Details

• The "Show & Reload Page" button changes to display progress, but then simply hangs.

  

• DevTools: When the button is clicked, a beacon request is made to /wp-admin/admin-ajax.php, but does not succeed, and a corresponding error appears in the JS console: [Error] Failed to load resource: The URL can’t be shown (post.php, line 0).

  

• The same error appears whether on /wp-admin/post.php or /wp-admin/post-new.php.

[dmsnell]

Maybe a duplicate of #646 - something related to a cross-origin rejection stemming from the iframe?

[adamziel]

This appears to be working now, so I'm going to close this issue:

CleanShot.2024-03-22.at.00.13.28.mp4

Would you confirm it indeed works for you @ironprogrammer? If not, please reopen.

[ironprogrammer]

Thanks for checking on this, @adamziel! In my testing, the issue remains in Safari (tested 6.5 / 6.4; normal / private browsing), but works as expected in Chrome. Would you please confirm the browser used in your test?

Environment

• Hardware: MacBook Pro Apple M1 Pro
• OS: macOS 14.4.1
• Browser: Safari 17.4.1, Google Chrome 123.0.6312.87

(Also note that in 6.5, the "Custom fields" option has been moved to the General tab.)

It doesn't look like I have access to re-open the issue 😬.

[ellatrix]

I have the same problem

[adamziel]

@bgrgicak does this look similar to the other Safari error you've seen recently?

[bgrgicak]

The issue looks the same as the Safari bug I explored.

I can take a look at this, maybe there is something more general we can do with redirects to avoid these issues.

[bgrgicak]

Here is a minimal example that will fail in Playground. The code can be added after this line .

To recreate the issue, open this URL in Safari: http://localhost:5400/website-server/?login=no&url=%2Fredirect-test.php

The same script works if called from an NGINX server, I will keep investigating further. My next step is to modify the response from Playground to 100% match the response from NGINX and see if this fixes the issue.

I also took a look at WebKit Bugzilla, but couldn't find any similar issues.

	await php.writeFile(
		'/wordpress/redirect-test.php',
		`<?php
		if (isset($_GET['stop-redirect'])) {
			echo 'Response from redirect-test.php';
			return;
		}
		if (isset($_GET['absolute'])) {
			header("Location: ${options.siteUrl}/redirect-test.php?absolute=1&stop-redirect=1");
		} else {
			header("Location: /redirect-test.php?stop-redirect=1");
		}
		exit;
		?>`
	);

[bgrgicak]

I confirmed this is a Safari bug and opened a bug report in WebKit bugzilla.

As a next step I will work on a Safari fix that will force all Location headers to be absolute URLs before returned by the Service Worker.

[brandonpayton]

I confirmed this is a Safari bug and opened a bug report in WebKit bugzilla.

Good find!