WordPress.org

Make WordPress Core

#45253 closed defect (bug) (fixed)

"Unhandled promise rejection" in 5.0-RC2

Reported by: jsmoriss Owned by:
Milestone: 5.2 Priority: normal
Severity: major Version: 5.0
Component: Editor Keywords: has-patch commit
Focuses: javascript Cc:

Description

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 }
wp-polyfill-ecmascript.min.js:2:29718 

Attachments (3)

45253.diff (1.1 KB) - added by Chouby 17 months ago.
actual-with-issue.gif (3.8 MB) - added by ryankienstra 16 months ago.
The 'Uncaught (in promise)' error appearing on updating a post
after-fix.gif (579.3 KB) - added by ryankienstra 16 months ago.
With 45253.diff applied, there is no console error

Change History (38)

#1 @SergeyBiryukov
20 months ago

  • Focuses javascript added
  • Version changed from trunk to 5.0

#2 @jsmoriss
20 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
Response

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(), … }
wp-polyfill.min.js:2:29718
T/</n<
http://.../wp-includes/js/dist/vendor/wp-polyfill.min.js:2:29718
[89]</n.exports
http://.../wp-includes/js/dist/vendor/wp-polyfill.min.js:1:25719
T/<
http://.../wp-includes/js/dist/vendor/wp-polyfill.min.js:2:29595
[51]</n.exports
http://.../wp-includes/js/dist/vendor/wp-polyfill.min.js:1:16271
<anonymous>
http://.../wp-includes/js/dist/vendor/wp-polyfill.min.js:1:30590
m
http://.../wp-includes/js/dist/vendor/wp-polyfill.min.js:1:30435
x
http://.../wp-includes/js/dist/vendor/wp-polyfill.min.js:1:30455

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


19 months ago

#4 @jsmoriss
19 months 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.

js.

#5 @jsmoriss
19 months 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.

js.

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


19 months ago

#7 @jsmoriss
19 months ago

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

#8 @matveb
19 months 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
19 months 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).

js.

#10 @ocean90
19 months ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

#11 @aduth
19 months 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:

https://github.com/WordPress/wordpress-develop/commit/0154e309d8c87644ea819c928a73bcef9f373977#diff-b37185844779d2892c129026826850eeR1895

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
19 months 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?

js.

#13 @jsmoriss
19 months 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.

js.

Last edited 19 months ago by jsmoriss (previous) (diff)

#14 @jsmoriss
19 months ago

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

js.

#15 @pento
19 months ago

  • Milestone changed from Awaiting Review to 5.0.1

#16 @pento
19 months ago

  • Milestone changed from 5.0.1 to 5.0.2

#17 @pento
19 months ago

  • Milestone changed from 5.0.2 to 5.0.3

#18 @audrasjb
18 months 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
18 months 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
18 months 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

js.

@Chouby
17 months ago

#21 @Chouby
17 months ago

  • Keywords has-patch added

I encountered the same issue. In fact we get this error because it's currently not possible to use the function use_block_editor_for_post() when $_GET['meta-box-loader'] is set, due to the check_admin_referer() always failing in this function.

When updating the post in the block editor, it fires a POST request such as:

http://mysite.com/wp-admin/post.php?post=145&action=edit&meta-box-loader=1&_wpnonce=1c971368b2&_locale=user

This request includes two different parameters _wp_nonce. One in $_GET, the other in $_POST. check_admin_referer() uses $_REQUEST, so takes the value of $_POST. Thus check_admin_referer( 'meta-box-loader' ) fails as it expects the value included in $_GET.

Changing one of the 2 nonces name fixes the issue.


#22 @ocean90
17 months ago

  • Keywords needs-testing added
  • Milestone set to 5.1.1

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


17 months ago

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


16 months ago

This ticket was mentioned in Slack in #core by lukecarbis. View the logs.


16 months ago

@ryankienstra
16 months ago

The 'Uncaught (in promise)' error appearing on updating a post

@ryankienstra
16 months ago

With 45253.diff applied, there is no console error

#26 @ryankienstra
16 months ago

45253.diff Seems To Fix This

Steps To Reproduce

  1. Clone the WPSSO plugin, and checkout this commit:

git clone https://github.com/SurniaUlula/wpsso.git
cs wpsso
git checkout 50f78

  1. Activate WPSSO
  2. Create a new post
  3. Click "Save Draft"
  4. Expected: the post saves
  5. Actual: as reported earlier, there's an 'Uncaught (in promise)' error in the JS console

With 45253.diff applied
When @Chouby's 45253.diff is applied, there is no console error

Last edited 16 months ago by ryankienstra (previous) (diff)

This ticket was mentioned in Slack in #core by ryankienstra. View the logs.


16 months ago

#28 @lukecarbis
16 months ago

  • Keywords commit added; needs-testing removed

This ticket was mentioned in Slack in #core by pbiron. View the logs.


16 months ago

#30 @lukecarbis
16 months ago

  • Milestone changed from 5.1.1 to 5.1.2

#31 @ocean90
16 months ago

In 44938:

Meta Boxes: Use a unique name for the nonce of the meta box loader.

Fixes a case where saving in the block editor fails if there are two _wpnonce arguments in the request, one overriding the other so that use_block_editor_for_post() wasn't able to check the nonce properly.

Props Chouby.
See #45253.

#32 @ocean90
16 months ago

  • Keywords fixed-major added

#33 @jsmoriss
15 months ago

It's great that the nonce validation was fixed, but should nonce failures cause a web browser to eat CPU endlessly like that?

Shouldn't there be somekind of handling of failed nonce validation?

js.

#34 @desrosj
15 months ago

  • Keywords fixed-major removed
  • Milestone changed from 5.1.2 to 5.2

Seems 5.1.2 will not be happening now. Moving this to 5.2 and closing out.

#35 @pento
15 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.