Make WordPress Core

Opened 3 months ago

Last modified 6 days ago

#45253 reopened defect (bug)

"Unhandled promise rejection" in 5.0-RC2

Reported by: jsmoriss Owned by:
Milestone: Priority: normal
Severity: major Version: 5.0
Component: Editor Keywords:
Focuses: javascript Cc:


When saving a post, the save never completes, and I get the following error in the web browser console (url and nonce redacted):

Unhandled promise rejection 
Response { type: "basic", url: "http://********/wp-admin/post.php?post=1086&action=edit&meta-box-loader=1&_wpnonce=********&_locale=user", redirected: false, status: 403, ok: false, statusText: "Forbidden", headers: Headers, bodyUsed: false }

Change History (20)

#1 @SergeyBiryukov
3 months ago

  • Focuses javascript added
  • Version changed from trunk to 5.0

#2 @jsmoriss
2 months ago

  • Summary changed from "Unhandled promise rejection" in 5.0-beta2-43852 to "Unhandled promise rejection" in 5.0-RC1-43944

FYI - This is still a problem in the latest RC. I can save a post with the current WordPress version and the Gutenberg plugin, but cannot save a post in WordPress 5.0:

Unhandled promise rejection

bodyUsed: false

headers: Headers {  }

ok: false

redirected: false

status: 403

statusText: "Forbidden"

type: "basic"

url: "http://.../wp-admin/post.php?post=1086&action=edit&meta-box-loader=1&_wpnonce=********&_locale=user"

<prototype>: ResponsePrototype { clone: clone(), arrayBuffer: arrayBuffer(), blob: blob(), … }

This ticket was mentioned in Slack in #core-editor by jsmoriss. View the logs.

8 weeks ago

#4 @jsmoriss
7 weeks ago

  • Severity changed from normal to major

Same problem in 5.0-RC2.

I'm testing with the metabox from WPSSO https://wordpress.org/plugins/wpsso/.

It's working fine in all versions of Gutenberg, including the latest, but not in WP 5.0.

This affects about 15-20k users.


#5 @jsmoriss
7 weeks ago

FYI - When clicking "Update", the following two requests are made:

XXX.XXX.XXX.XXX - USERNAME [01/Dec/2018:16:54:25 +0000] "POST /wp-json/wp/v2/pages/1086?_locale=user HTTP/1.1" 200 4514 "http://XXXXXXXX/wp-admin/post.php?post=1086&action=edit" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:63.0) Gecko/20100101 Firefox/63.0"

XXX.XXX.XXX.XXX - USERNAME [01/Dec/2018:16:54:26 +0000] "POST /wp-admin/post.php?post=1086&action=edit&meta-box-loader=1&_wpnonce=396c1f7c35&_locale=user HTTP/1.1" 403 2923 "http://XXXXXXXX/wp-admin/post.php?post=1086&action=edit" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:63.0) Gecko/20100101 Firefox/63.0"

Note that this is a password protected test site running WP 5.0-RC2 and WPSSO, nothing else.

A different password protected site running WP 4.9.8 with Gutenberg 4.6.1 runs just fine.


This ticket was mentioned in Slack in #core-editor by jsmoriss. View the logs.

7 weeks ago

#7 @jsmoriss
7 weeks ago

  • Summary changed from "Unhandled promise rejection" in 5.0-RC1-43944 to "Unhandled promise rejection" in 5.0-RC2

#8 @matveb
7 weeks ago

  • Resolution set to fixed
  • Status changed from new to closed

This should be addressed after #43960. Please, follow up if you still experience issues.

#9 @jsmoriss
7 weeks ago

This doesn't seem to be related with my issue - post saving works fine with WP 4.9.8 and Gutenberg 4.6.1, but creates a console error in WP 5.0-RC3 and saving never ends (just keeps driving up CPU usage on the browser side).


#10 @ocean90
7 weeks ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

#11 @aduth
7 weeks ago

The merge of Gutenberg to core included an additional nonce validation for a 'meta-box-loader', which explains the difference between the plugin and 5.0:


Do you have any reason to think that your plugin would be interfering with the check in the line above? The 403 Forbidden response from the error is a standard "invalid nonce" error.

#12 @jsmoriss
7 weeks ago

I don't see how it would interfere - the plugin has it's own nonce field and validation for its own form data.

Why isn't the 403 being handled? Right now, the block editor appears to keep re-trying and driving up CPU usage in the browser. If you're going to add a check for something, you should handle the results of that check, right?


#13 @jsmoriss
6 weeks ago

By commenting various lines, I was able to track down the issue to a single function call used during the post save process:

use_block_editor_for_post( $post_id )

If this function is called, it results in a 403, which is unhandled and hangs the browser.


Last edited 6 weeks ago by jsmoriss (previous) (diff)

#14 @jsmoriss
6 weeks ago

FYI - The use_block_editor_for_post_type() function is safe to use, but use_block_editor_for_post() crashes the browser.


#15 @pento
6 weeks ago

  • Milestone changed from Awaiting Review to 5.0.1

#16 @pento
6 weeks ago

  • Milestone changed from 5.0.1 to 5.0.2

#17 @pento
5 weeks ago

  • Milestone changed from 5.0.2 to 5.0.3

#18 @audrasjb
3 weeks ago

  • Keywords dev-feedback added
  • Milestone changed from 5.0.3 to 5.1

5.0.3 is going to be released in a couple of weeks. We are currently sorting the remaining tickets in the milestone. It doesn't appear that ticket can be handled in the next couple of weeks (no patch and still needs some discussion… and maybe its a close). Let's address it in 5.1 (if needed) which is coming in February. Feel free to change/ask to change the milestone if you think the issue can be quickly resolved.

#19 follow-up: @pento
6 days ago

  • Keywords dev-feedback removed
  • Milestone 5.1 deleted
  • Resolution set to worksforme
  • Status changed from reopened to closed

I'm unable to reproduce this issue with the WPSSO plugin installed.

#20 in reply to: ↑ 19 @jsmoriss
6 days ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

Replying to pento:

I'm unable to reproduce this issue with the WPSSO plugin installed.

That's because I coded around it.

 * Calling use_block_editor_for_post() in WordPress v5.0 during post save crashes
 * the web browser. See https://core.trac.wordpress.org/ticket/45253 for details.
 * Only call use_block_editor_for_post() if using an earlier version of WordPress.
global $wp_version;

if ( version_compare( $wp_version, '5.0', '>=' ) ) {    // Assume can edit.
        $can_edit_id = true;
} elseif ( use_block_editor_for_post( $post_id ) ) {
        $can_edit_id = true;

From https://plugins.trac.wordpress.org/browser/wpsso/trunk/lib/com/util.php#L1144


Note: See TracTickets for help on using tickets.