XMLHttpRequest failure: synchronous XHR request during page dismissal

[eli-darkly]

Originally reported in this comment on the more general issue #126.

Symptom

In recent versions of Chrome, the browser console shows this warning: Failed to execute 'send' on 'XMLHttpRequest': Failed to load 'https://events.launchdarkly.com/events/bulk/________': Synchronous XHR in page dismissal

This issue refers specifically to the case where it mentions "synchronous XHR in page dismissal", not to any other XMLHttpRequest failures.

Background

• The LaunchDarkly SDK generates analytics events to report user data and feature flag usage statistics to LaunchDarkly.
• To avoid making lots of HTTP requests, it accumulates the events in an array and sends them to LaunchDarkly at regular intervals (the flush interval). The default is two seconds.
• If the user closes the browser or navigates off of the page, and some events have not yet been sent, you could lose some of your analytics data.
• Therefore, the SDK uses a beforeunload event handler to try to deliver the events just before the page is closed. Asynchronous actions cannot be done in beforeunload, so it makes a synchronous HTTP request in this one case.
• Synchronous requests during beforeunload are now disallowed in Chrome.

Possible workarounds

We have not yet investigated this issue in depth and do not know if it'll be possible to preserve all of the current functionality. Here are two possible workarounds for now:

1. To reduce—but not eliminate—the chance of these warnings happening, you can set a lower flushInterval in your configuration, such as 1000 (one second). That will make it somewhat less likely that there are events still waiting to be sent when the page is closed. The tradeoff is that the browser will be making more frequent HTTP requests to LaunchDarkly.

2. In case you don't require analytics data at all—that is, you still want feature flagging to work, but you don't care about seeing users and flag statistics on your dashboard—you can simply set sendEvents: false in your client configuration. That will make the client not send any event data at any time, so the warnings should never happen.

Unfortunately, it is not currently possible to just remove the beforeunload handler that the SDK has added, because removeEventListener requires that you specify the original handler function and there's no way to access that from outside of the SDK.

Possible fixes

1. We are looking into the viability of using sendBeacon.

2. We should also make it possible to disable the "send events before page close" behavior entirely if there's no other way.

We're continuing to look into this and will add comments here if we have any more possible workarounds or fixes.

[eli-darkly]

We are working on a patch release which will simply disable this functionality (sending leftover events on page unload) in Chrome 73 and above. Behavior in other browsers will be unchanged.

After that patch, we will be working on an update to avoid the use of synchronous XHR in general.

[eli-darkly]

We've just released version 2.9.7, which is the patch mentioned in the previous comment. Deploying this patch should stop the errors in Chrome.

Note that pending events at page unload time were already being lost in Chrome 73, and they still will be with this patch. We will need to do further work to prevent events from being dropped. In the meantime, if you set flushInterval to a smaller number in your client configuration (the default is 2000 milliseconds) then there will be less chance of events being lost; however, that also means the SDK will be making HTTP requests to LaunchDarkly more often (if you are generating events frequently).

[redroot]

@eli-darkly patch reduced the errors considerably already, much appreciated

[eli-darkly]

@redroot Are you still seeing some—that is, the same "synchronous XHR" messages? Or are they different errors?

[redroot]

We have one or two of the same error an hour since we shipped the 2.9.7 patch (see the drop off towards the right here) - we often have users keep their pages open for a while so I've put it down to that, still diminishing too

[eli-darkly]

@redroot Hopefully that's it. If the rest of them don't go away soon, or if you start seeing more, that would be unexpected so please let us know.

Meanwhile, we've been looking into using the Beacon API instead of XHR during page unload, which is a logical approach since it's basically what Beacon was designed for. It seems feasible, but there have been a few hassles due to very inconsistent behavior across browsers when using a cross-origin URL, so we need to make sure what we do will work for everyone.

[eli-darkly]

We still need to revisit this with an eye toward possibly using the Beacon API in browsers that support it (the very inconsistent support is the main obstacle), so we'll keep this issue open.

[tracked internally as 36705]

[cafesanu]

Seems like adding disableSyncEventPost did the trick for us https://launchdarkly.github.io/js-client-sdk/interfaces/_launchdarkly_js_client_sdk_.ldoptions.html#disablesynceventpost

const LaunchDarklyProvider = await asyncWithLDProvider({
  clientSideID: ...,
  options: { disableSyncEventPost: true },
});

[eli-darkly]

@cafesanu Be aware that this may result in some analytics event data being lost if it was generated in the last couple of seconds before a page/tab is closed.

I know this issue has been around for quite a while, and we do still have an intention to implement this feature in a better way.

[shirly-chen-awx]

@eli-darkly any updates about this? do we support sendBeacon now?

[eli-darkly]

Unfortunately, there hasn't been progress on this yet. We are working on larger changes to the SDK, and this is likely to be rolled into those.

[pm0u]

We are evaluating your service and dropped analytics events are a blocker for stakeholders with Chrome so widely used - any further updates on timeline here? Chrome 73 is now 4 years old and sendBeacon has >95% support according to caniuse.