See https://groups.google.com/a/chromium.org/forum/m/#!msg/blink-dev/LnqwTCiT9Gs/p-WPDNO9BgAJ

Chrome has seen 7% improvement in FCP at 75th percentile experimenting with this change. They're shipping this in Chrome 75.

Before doing this, we need to ensure sendBeacon doesn't have any too bad bugs.

Sounds like Chrome is delaying their plans: https://bugzilla.mozilla.org/show_bug.cgi?id=1532555#c6

Chrome 80 is going to ship the change. https://www.chromestatus.com/feature/4664843055398912

The dismissal of syncXHR during unload is highly incompatible and causes big issues with SAP enterprise customers. Google postponed the changes to Chrome 80 (per group policy or flags still enabled until Chrome 88) due to discussion with SAP (among others).

SAP relies in various products on syncXHR in the unload event to do session handling. Once the browser is closed, refreshed or user navigates from one application to another we sent a syncXHR request during unload event to the server to trigger the logoff. The logoff not only unfreezes resources (session close) but also unlock database objects. If this request doesn’t reach the server the locks remains and nobody can access this object until session timeout (normally between 15-30min).

We used syncXHR also because it is important that the logoff request reaches the server bevor a next applications started especially if both locks the same object. With a async approach is nearly impossible to get the right order of the requests (logoff and then the next start) on the server.

As Google insists of removing the syncXHR and also window.open during unload SAP decided to use sendBeacon and tried with various other mechanism to ensure the synchronous behavior.

SAP customers must upgrade all their onprem systems which are normally mission critical to get our workarounds. Otherwise this change will break the business. Normally it takes years to upgrade all systems as the testing effort is immense and the risk of introducing the new issue are very high. The finacial impactof this change is very high for customers.

Therefore we have to main issues or requirements:
• sendBeacon must work reliable in all cases. To define it more precise: sendBeacons created in the unload event of the main window and/or iframes must be sent out during F5, tab close and complete browser close.

Our tests shows that Firefox not sending a sendBeacon out once the browser is closed (tested with Firefox 72.0.1). It seems to work if one tab remains open or in the F5 refresh case.

• Depending on the timeframe to opt-in the features to give enterprise customer more time to plan, upgrade and test the systems.

Until today SAP did not provide for all scenarios a solution.

Do you have any contact driving this topic so that we could dicuss it in more detail?

I create a report for sendBeacon not sent out during browser close ... see Bug 1609653 sendBeacon doesn't work on browser close

need-info Nhi, to find out priority for this.

Based on comment 4, I think we should bring the webcompat team into this to help determine priority.

Mike, Do you mean the priority for Bug 1609653? I agree we should make reasonable efforts to ensure Firefox and SAP work together, especially for enterprise customers.

Thorsten, Have you tested if Chrome is able to send beacons when the browser is also closed (not just a tab)?

Also, I'm not aware of any timing from our side to unship sync XHR, but it certainly won't be before Chrome.

Yes, we have tested Chrome/Chromium based browsers during complete browser close (no tab remain open). It seems Chrome sends sendBeacon reliable out if they are created within the main window, but nor reliable once created in IFrames. We tested with 5 sendBeacons created in the main window and 5 from three different embedded iframes. Sometimes all are send and sometimes only from the main window. Normally at least one from each IFrame.

SAP still discuss this topic with Chrome as they recently declined to fix it. See https://bugs.chromium.org/p/chromium/issues/detail?id=1035327. But our customers expects a reliable behavior not affected the daily business.

(In reply to Mike Taylor [:miketaylr] from comment #8)

Mike, Do you mean the priority for Bug 1609653? I agree we should make reasonable efforts to ensure Firefox and SAP work together, especially for enterprise customers.

Sorry, yes, bug 1609653.

Also, I'm not aware of any timing from our side to unship sync XHR, but it certainly won't be before Chrome.

This is true. However, I think it is reasonable to expect Firefox to eventually follow Chrome in removing sync XHR.

I don't see an urgent need for us to remove sync XHR. We probably will do it eventually, but not before Chrome.