Synchronous XMLHttpRequest on the main thread is deprecated

[atomicjack]

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/.

[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?

[atomicjack]

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]

Chrome error

[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.

[atomicjack]

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]

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.

[azaozz]

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.

[iseulde]

#37487 was marked as a duplicate.

[iseulde]

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]

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.

[iseulde]

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

Fixed in [38425].