WordPress.org

Make WordPress Core

Opened 4 months ago

Last modified 7 weeks ago

#52933 new defect (bug)

Error in browser console when newly published post is previewed a second time

Reported by: garethhadfield Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Editor Keywords:
Focuses: javascript, rest-api Cc:

Description

Summary of Problem:
When a new post or page is created then published, then [Preview] | [Preview in new tab] is selected, no problem occurs the first time. However if [Preview in new tab] is clicked a second time then the the console records this error (assuming post id 15):
Failed to load resource: the server responded with a status of 400 (Bad Request) https://example.com/wp-json/wp/v2/posts/15/autosaves?_locale=user

The error continues to occur every second time [Preview] | [Preview in new tab] is clicked.

I have reproduced this on a fresh install of 5.7 both on local system and on hosted web server.

Steps to Reproduce:
1) Login and create a new Post by clicking New | Post
2) Give the post a name and click Publish | Publish | x
3) Open the browser's javascript console
4) Click [Preview] | [Preview in new tab]
5) When the preview window appears, close it or tab back to the edit post screen (at this stage no error in console)
6) Click [Preview] | [Preview in new tab] again (error appears in console)

Change History (5)

#1 @garethhadfield
4 months ago

If anyone would like I can provide a login for a test website here http://wp01.opdiv.com

On this site, the console error is
Failed to load resource: the server responded with a status of 400 (Bad Request) http://wp01.opdiv.com/wp-json/wp/v2/posts/17/autosaves?_locale=user

And the file http://wp01.opdiv.com/wp-json/wp/v2/posts/17/autosaves?_locale=user
returns:
{"code":"rest_cannot_read","message":"Sorry, you are not allowed to view autosaves of this post.","data":{"status":401}}

Last edited 4 months ago by SergeyBiryukov (previous) (diff)

#2 @SergeyBiryukov
4 months ago

  • Milestone changed from Awaiting Review to 5.7.1

Hi there, welcome back to WordPress Trac! Thanks for the report.

Just noting that I was able to reproduce the issue as described. Moving to 5.7.1 for investigation.

Here's the response from the Autosaves controller that causes the error:
{"code":"rest_autosave_no_changes","message":"There is nothing to save. The autosave and the post content are the same.","data":{"status":400}}

#3 @peterwilsoncc
4 months ago

  • Focuses ui administration removed
  • Milestone changed from 5.7.1 to 5.8
  • Version 5.7 deleted

I've tested this and can reproduce the issue but it appears it was introduced some time ago.

The earliest I've been able to reproduce it in is at the start of the 5.6 release cycle (commit r48683) but to test before that I need to change how I test due to issues with NPM locally.

As this bug has been around for a while, I'm moving in to the next major release rather than the next maintenance release.

#4 @Rahmohn
3 months ago

I've tested this and can reproduce the issue too.

The issue happens if there is already an autosave and the user clicks in "Preview in new tab" because this button always tries to autosave the post. So another way to reproduce this issue is by clicking on "Preview in new tab", reload the page and try to preview again.

Other than that, Autosaves controller deletes the autosave when the post data is the same. So the next time the user tries to preview the issue doesn't happen.

It's not clear to me the best approach to fix it. We can prevent the "Preview in new tab" button to send the request when the content hasn't changed. The behavior would be like the "Update" button. The second approach is changing the Autosave controller to return the previous autosave if the content is the same instead of a Bad Request (HTTP 400).

#5 @desrosj
7 weeks ago

  • Milestone changed from 5.8 to Future Release

The 5.8 beta 1 deadline is today, and this one still requires a patch. I'm going to punt, but if someone is able to tackle this before beta 1 is shipped later today, it can be moved back.

Note: See TracTickets for help on using tickets.