Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Emulate the keepalive option by doing a synchronous request #700

Closed
alexturpin opened this issue Apr 16, 2019 · 3 comments
Closed

Emulate the keepalive option by doing a synchronous request #700

alexturpin opened this issue Apr 16, 2019 · 3 comments

Comments

@alexturpin
Copy link

Historically, when sending data from browsers to server before the page is closed (e.g. through the beforeunload event), XHR synchronous requests have been used.

This is now deprecated in Chrome, with likely more browsers to follow. The prescribed solution is either navigator.sendBeacon (which only works for POST) or fetch with a keepalive flag.

It's not possible to properly polyfill the keepalive flag of course, but sending a synchronous XHR request is a good alternative for older browsers. Would you guys accept a PR that makes synchronous requests when the keepalive flag is set to true, with corresponding documentation in the README? This would make it so that people could use a single API call to support keepalive requests on beforeunload, instead of having to do lots of code branching.

@mislav
Copy link
Contributor

mislav commented Apr 17, 2019

Hi, thank you for the thoughtful feature request.

There are pros and cons to us implementing this, and I think you've done a good job outlining them. The technical aspect of this isn't hard (it would likely be only 2 lines of code), and it would certainly be useful is keepalive setting could be used in browsers old and new alike.

However, synchronous XHRs are just bad. There's a reason why browsers are deprecating/disallowing them now. They block the whole thread, freezing up the browser tab until they are done. What if the site that they are making the request to isn't responsive?

We cannot in good consciousness support people using synchronous XHR.

My advice: just use sendBeacon when available, with no fallback, since it's supported pretty well across Chrome, Firefox, Safari 11.1+, and Edge 14+.

@mislav mislav closed this as completed Apr 17, 2019
@alexturpin
Copy link
Author

alexturpin commented Apr 17, 2019

Thanks for taking the time to answer!

sendBeacon has a few shortcomings that make it unusable in our case, and likely for others.

  • It only works for POST requests
  • In Chrome it has a data limit of 64kb

fetch with keepalive is then the obvious alternative. However, the problem then becomes that I cannot use this polyfill in my application to streamline code because it will silently fail for polyfilled browsers. I find myself having to store whether fetch is natively available or not before including the polyfill, and then using that to determine whether to use fetch with keepalive for native browsers or synchronous XHR for the rest, which definitely isn't ideal. I'm open to suggestions on how to deal with that in a cleaner way.

At the very minimum, I would suggest adding a notes under the "Caveats" section of the README with other potential solutions. Ideally, the library would throw when keepalive is used with it instead of failing silently.

@mislav
Copy link
Contributor

mislav commented Apr 18, 2019

I find myself having to store whether fetch is natively available or not before including the polyfill, and then using that to determine whether to use fetch with keepalive for native browsers or synchronous XHR for the rest, which definitely isn't ideal.

Using feature detection is better. It's possible that not all browsers that have initially implemented window.fetch have also implemented keepalive.

const browserSupportsKeepalive = 'keepalive' in new Request('')

// later:
if (browserSupportsKeepalive) {
  fetch(url, {keepalive: true})
} else {
  new XMLHttpRequest
}

At the very minimum, I would suggest adding a notes under the "Caveats" section of the README

We welcome PRs to improve documentation! I would suggest first adding the note about keepalive to the bottom of https://github.github.io/fetch/#caveats (in the gh-pages git branch) and then linking to that section from Caveats in the README.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 1, 2020
ppichate2531 referenced this issue in ppichate2531/css Mar 12, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants