WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#33349 closed defect (bug) (fixed)

Synchronous XMLHttpRequest on the main thread is deprecated

Reported by: atomicjack Owned by:
Milestone: 4.7 Priority: normal
Severity: normal Version: 4.3
Component: Editor Keywords: has-patch needs-testing
Focuses: javascript Cc:

Description

When browsing from the Add New Page to the Add New Post, the console gave the following error:

Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check http://xhr.spec.whatwg.org/.

Attachments (4)

synchronous.png (142.0 KB) - added by atomicjack 6 years ago.
Chrome error
33349.diff (354 bytes) - added by swissspidy 5 years ago.
33349.patch (953 bytes) - added by iseulde 5 years ago.
33349.2.patch (1.1 KB) - added by iseulde 5 years ago.

Download all attachments as: .zip

Change History (17)

#1 follow-up: @helen
6 years ago

  • Component changed from Administration to General
  • Focuses administration removed
  • Keywords reporter-feedback added

I'm not seeing this in Firefox dev - what browser are you in, is this a clean install of trunk, and can you reproduce this in earlier versions of WP?

#2 in reply to: ↑ 1 @atomicjack
6 years ago

  • Keywords needs-patch added; reporter-feedback removed

Replying to helen:

I'm not seeing this in Firefox dev - what browser are you in, is this a clean install of trunk, and can you reproduce this in earlier versions of WP?

This is in Chrome 46, and was also in Chrome 45, which has now hit stable.

Present in 4.3.1 trunk and 4.3.

Screenshot attached.

@atomicjack
6 years ago

Chrome error

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


5 years ago

#4 follow-up: @swissspidy
5 years ago

  • Component changed from General to Administration
  • Focuses javascript added

It's only a warning, not an error, and I get it too when I'm on the "Add New Post" screen and refresh the page.

The reason is the request to admin-ajax.php to remove the post lock, see https://core.trac.wordpress.org/browser/trunk/src/wp-admin/js/post.js?rev=35395#L401.

Introduced in [26995]

Edit: The easy fix would be to remove async: false, but perhaps that would lead to the post lock not being removed. Needs testing.

Last edited 5 years ago by swissspidy (previous) (diff)

#5 in reply to: ↑ 4 @atomicjack
5 years ago

Replying to swissspidy:

It's only a warning, not an error, and I get it too when I'm on the "Add New Post" screen and refresh the page.

The reason is the request to admin-ajax.php to remove the post lock, see https://core.trac.wordpress.org/browser/trunk/src/wp-admin/js/post.js?rev=35395#L401.

Introduced in [26995]

Edit: The easy fix would be to remove async: false, but perhaps that would lead to the post lock not being removed. Needs testing.

Is there a reason it can't be done with async?

@swissspidy
5 years ago

#6 follow-up: @swissspidy
5 years ago

  • Keywords has-patch needs-testing added; needs-patch removed

Perhaps @azaozz can tell us why async is set to false here.

I assume it was done to ensure the call was really made before leaving the page (blocking), but it should also work with async: true. The attached patch removes the option. Just needs some testing.

#7 in reply to: ↑ 6 @azaozz
5 years ago

Replying to swissspidy:

Right, async: false was producing the best results when testing in all current browsers at the time. It was and still is a bit of hit-and-miss, the request doesn't seem to fire in some browsers and in some circumstances. Thinking we can remove the async setting as it is/will be ignored by the browsers.

The removal of post locks (AJAX request on page unload) needs another round of testing in all current browsers, and perhaps a better way to do it.

#8 @swissspidy
5 years ago

  • Milestone changed from Awaiting Review to Future Release

#9 @iseulde
5 years ago

#37487 was marked as a duplicate.

@iseulde
5 years ago

#10 @iseulde
5 years ago

Uploaded a new patch that makes use of the Beacon API instead. The browser may also ignore the request if async is set to true and the page is already unloading, see https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon:

User agents will typically ignore asynchronous XMLHttpRequests made in an unload handler. To solve this problem, analytics and diagnostics code will typically make a synchronous XMLHttpRequest in an unload or beforeunload handler to submit the data. The synchronous XMLHttpRequest forces the User Agent to delay unloading the document, and makes the next navigation appear to be slower. There is nothing the next page can do to avoid this perception of poor page load performance.

More info on #37487.

@iseulde
5 years ago

#11 @iseulde
5 years ago

  • Component changed from Administration to Editor
  • Milestone changed from Future Release to 4.7

Patch uses navigator.sendBeacon to send a POST request when FormData and sendBeacon are available, otherwise it uses the previous method of sending a synchronous one.

#12 @iseulde
5 years ago

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

I forgot to link the commit and mark this as fixed. Apologies.

Fixed in [38425].

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


5 years ago

Note: See TracTickets for help on using tickets.