WordPress.org

Make WordPress Core

Opened 11 months ago

Closed 5 months ago

#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 7 months ago.
actual-with-issue.gif (3.8 MB) - added by ryankienstra 7 months ago.
The 'Uncaught (in promise)' error appearing on updating a post
after-fix.gif (579.3 KB) - added by ryankienstra 7 months ago.
With 45253.diff applied, there is no console error

Change History (38)

#1 @SergeyBiryukov
11 months ago

  • Focuses javascript added
  • Version changed from trunk to 5.0

#2 @jsmoriss
10 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.


10 months ago

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


10 months ago

#7 @jsmoriss
10 months ago

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

#8 @matveb
9 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
9 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
9 months ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

#11 @aduth
9 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
9 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
9 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 9 months ago by jsmoriss (previous) (diff)

#14 @jsmoriss
9 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
9 months ago

  • Milestone changed from Awaiting Review to 5.0.1

#16 @pento
9 months ago

  • Milestone changed from 5.0.1 to 5.0.2

#17 @pento
9 months ago

  • Milestone changed from 5.0.2 to 5.0.3

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

#21 @Chouby
7 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
7 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.


7 months ago

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


7 months ago

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


7 months ago

@ryankienstra
7 months ago

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

@ryankienstra
7 months ago

With 45253.diff applied, there is no console error

#26 @ryankienstra
7 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 7 months ago by ryankienstra (previous) (diff)

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


7 months ago

#28 @lukecarbis
7 months ago

  • Keywords commit added; needs-testing removed

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


6 months ago

#30 @lukecarbis
6 months ago

  • Milestone changed from 5.1.1 to 5.1.2

#31 @ocean90
6 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
6 months ago

  • Keywords fixed-major added

#33 @jsmoriss
5 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
5 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
5 months ago

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