Avoid synchronous xhr by using window.sendBeacon when available

[talldan]

Description

While looking at #14986 I noticed an error occurring with one of the preview tests:

DOMException: Failed to execute 'send' on 'XMLHttpRequest': 
Failed to load 'http://localhost:8889/wp-admin/admin-ajax.php': Synchronous XHR in page dismissal.

      at PostLockedModal.releasePostLock (../../http:/localhost:8889/wp-content/plugins/gutenberg/build/editor/index.js?ver=1555400628:8006:11)

Upon some investigation, it looks like this is a change in newer versions of chrome/chromium. Use of synchronous xhr requests have been disallowed in beforeunload. Not a great deal of evidence for this change, I found the stack overflow question first and then the thread on the chromium group after that:

• https://stackoverflow.com/questions/55676319/ajax-synchronous-request-failing-in-chrome
• https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/LnqwTCiT9Gs

We're using synchronous xhr requests in beforeunload to unlock a post when the page is closed. This fix detects whether the navigator.sendBeacon is available, and uses that instead to make the request.

How has this been tested?

Use browser dev tool network tab

1. Load up a post
2. Open chrome dev tools network tab
3. Filter to 'admin-ajax'.
4. Enabled the 'Preserve Logs' option.
5. Refresh the page
6. Check that a request to /wp-admin/admin-ajax.php was made. The request should have an action of 'wp-remove-post-lock' in its form data.

Tail logs

1. Tail server access logs (for the docker dev env I used docker logs -f <container_id>
2. Load up a post in your browser
3. Close the browser tab
4. Check that there's a request to /wp-admin/admin-ajax.php in the logs when closing the tab (when I tested I added a temporary query string to the url to verify that it was the right request in the logs).

Other ways of testing.

• Trigger the beforeUnload event from the browser console (window.dispatchEvent(new Event('beforeunload'));) and monitor the network requests
• Use a network sniffer like Charles to catch the requests.

Types of changes

Bug fix (non-breaking change which fixes an issue)

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[talldan]

Also seeing this error message appear in my browser console when refreshing the page since upgrading to Chrome 73.0.3683.103.

[ocean90]

Related: https://core.trac.wordpress.org/changeset/38425 / https://core.trac.wordpress.org/ticket/33349

[talldan]

Not sure why the CI jobs aren't running for this PR. Will try some force pushing/rebasing to see if I can trigger it.

[draganescu]

The problem is no matter what I do, with latest Chrome even, I don't see any error in the console.
Yes the StackOverflow link got updated and it states:

Update: You can again, in v73 and v74, but it's slated (for now) to go away again in v75 unless there's more pushback

This change should make us safe from the incoming updates though

[draganescu]

In the Chromium forum:

To close the loop here: this change has been in experiment for last several months.
We didn't find any reports of problems and have seen a 7% improvement (i.e. reduction) in FCP at 75th percentile, a clear UX win. It is being turned on by default in M75

So we should merge this as bulletproofing.

[draganescu]

Tested the code locally and the posts get unlock fine when the user exits.