You update to WordPress 7.1, open Appearance > Editor and get a white screen. No error message, no spinner, nothing. Deactivating plugins and switching themes changes nothing, and Site Health says everything is fine.
If that sounds familiar, open the browser console. In the WordPress.org forum threads about this, the error is the same one every time:
TypeError: Promise.withResolvers is not a functionIt is thrown from edit-site.min.js, with React stack traces from react-dom.min.js underneath it. Your theme, plugins and server are not the problem. The browser is.
Confirm it is the browser in 30 seconds
Promise.withResolvers() is a fairly new JavaScript method. It returns a promise together with its resolve and reject functions, so code does not have to dig them out of a new Promise() callback. The editor code shipped with 7.1 calls it, and a browser that does not have it stops rendering the editor on the spot.
According to MDN’s compatibility data, support starts at:
- Chrome and Edge 119
- Firefox 121
- Safari 17.4 (macOS and iOS)
Anything older breaks. The most common case in the forums is Firefox 115 ESR, the extended support line that Mozilla kept alive for Windows 7, Windows 8.1 and older macOS versions. People on those machines cannot just click “update”, because newer Firefox releases do not install there.
To check, press F12 on the blank editor screen, open the Console tab and type:
typeof Promise.withResolversIf it prints "function", the browser is fine and your blank editor has a different cause, so go back to a plugin conflict test. If it prints "undefined", keep reading.
You can also check the version directly. In Firefox, open the menu and go to Help > About Firefox. In Chrome or Edge, visit chrome://version or edge://version.
The real fix: a supported browser
WordPress does not promise to work in old browsers. The core browser support policy covers the last two versions of Chrome, Firefox, Safari, Edge and Opera, plus any browser above 1% usage. Firefox 115 is far outside that window, so I would not expect core to add a workaround.
Updating the browser is the fix that sticks. One user in this forum thread fixed the exact same error just by moving to a current browser. Before that, a full plugin and cache test had changed nothing.
If the machine cannot run a newer Firefox, you still have options:
- Install a current Chromium-based browser if the operating system still supports one.
- Edit the site from a different device. A phone or tablet with an up-to-date Safari or Chrome is enough for quick changes.
- Put a lightweight Linux distribution on the old computer, which gets you a current Firefox on the same hardware.
On a site with several editors, ask whoever reports the blank screen for their browser version before you start disabling plugins. It saves a lot of time.
Stopgap: load a polyfill from a must-use plugin
If someone has to keep working on an old browser for a few more weeks, you can define the missing method yourself before WordPress loads its editor scripts. The polyfill is tiny because Promise.withResolvers() is only a shortcut for a pattern that old browsers already understand.
Do not put this in wp-includes or in the parent theme. Core and theme updates overwrite both. A must-use plugin loads on every admin page, survives updates and cannot be deactivated by accident.
Step 1. Create the mu-plugins folder
Connect over SFTP or your host’s file manager and go to wp-content. If there is no mu-plugins folder, create it. Back up wp-content first if you are not used to editing files on the server.
Step 2. Add the polyfill file
Create wp-content/mu-plugins/promise-withresolvers-polyfill.php with this content:
<?php
/**
* Plugin Name: Promise.withResolvers polyfill (wp-admin)
* Description: Stopgap for old browsers that show a blank editor on WordPress 7.1+.
*/
add_action( 'admin_print_scripts', function () {
$js = <<<'JS'
if ( typeof Promise.withResolvers !== 'function' ) {
Promise.withResolvers = function () {
var resolve, reject;
var promise = new Promise( function ( res, rej ) {
resolve = res;
reject = rej;
} );
return { promise: promise, resolve: resolve, reject: reject };
};
}
JS;
wp_print_inline_script_tag( $js );
}, 1 );Core prints the head scripts on admin_print_scripts at priority 20, so hooking in at priority 1 puts the polyfill on the page before any editor script runs. wp_print_inline_script_tag() outputs a normal inline <script> tag and passes through the wp_inline_script_attributes filter, so security plugins that add a CSP nonce still work.
The typeof check matters. Current browsers already have the native method, and the snippet leaves it alone, so everyone else on the team gets the native version.
Step 3. Reload the editor with a clean cache
Open the Site Editor in the old browser and do a hard reload (Ctrl+Shift+R). Run typeof Promise.withResolvers in the console again. It should now print "function".
💡 If the editor still stays blank but the console now shows a different “is not a function” or “is not defined” error, the browser is missing more than one modern API. At that point polyfilling turns into whack-a-mole, and a supported browser is the only fix worth your time.
Be realistic about this snippet. It only fills one gap. WordPress tests the editor against current browsers, so an old browser can still hit odd layout bugs or broken controls even when the editor loads. Treat it as a bridge until the machine is replaced, and delete the file once nobody needs it.
Why it looks like a theme problem
One forum poster got the blank editor with Twenty Twenty-Five and Twenty Twenty-Three but not with Twenty Twenty-Four. That makes it look like a theme bug, and people end up disabling things that have nothing to do with it.
Whatever the theme, the console error points at core’s edit-site script, because that is where the browser feature is missing. The poster with this result was on Firefox 115 ESR, and the moderator’s answer was the same: update the browser. Switching themes is not a fix, even when one theme happens to load.
This is also why classic debugging does not help much here. WP_DEBUG and the PHP error log stay empty because nothing fails on the server. If you want a refresher on what each debug tool actually catches, see how to properly debug in WordPress. For blank editors, the browser console comes first.
Some other editor errors also come from JavaScript rather than PHP. I covered a couple of them before: Minified Redux error #7 and the generic “Looks like something’s gone wrong” editor crash.
Avoid the same surprise on the next release
As of 2026-10-30, WordPress 7.2 is in beta. New editor code can rely on newer browser features at any time, and the support policy only promises the last two versions. If you manage sites for other people, put the browser requirement in your onboarding notes: a current Chrome, Edge, Firefox or Safari, kept on auto-update.
Test major updates on a staging copy, and open the editor there in the oldest browser your team still uses. A blank Site Editor on staging costs you five minutes. On production, it costs you a support thread.
TL;DR: If the Site Editor goes blank after updating to WordPress 7.1 and the console shows Promise.withResolvers is not a function, the browser is too old (older than Chrome/Edge 119, Firefox 121 or Safari 17.4). Update the browser or use another device. If you have to keep the old browser for a while, the mu-plugin polyfill above gets the editor loading again.
