Bug 204665 – sendBeacon on Safari 13 seeing high failure rates

• Status: RESOLVED
• Resolution: FIXED
• Component: Page Loading

[Yoav Weiss]

I've been getting multiple reports that `sendBeacon` on Safari 13 (both on iOS and macOS) is seeing significantly more failure reports than previous versions.
One provider that was measuring click based beacons was seeing 5x increase in failures, resulting in 1% of failures. A publishing platform that was using it to report back performance measurements was seeing a similar failure.
Talking to both, they are falling back to using sync XHR in Safari, which seems like a step in the wrong direction.

On top of that Simon Hearne at perf.now()[1] mentioned that as an analytics provider, he is seeing significantly slower unload times on iOS than on other platforms. That can be an indication that many folks use syncXHR instead of beacon there.


[1] https://perfnow.nl/

[Radar WebKit Bug Importer]

<rdar://problem/57522622>

[Yoav Weiss]

https://volument.com/blog/sendbeacon-is-broken seems relevant

[Chris Dumez]

(In reply to Yoav Weiss from comment #2)
> https://volument.com/blog/sendbeacon-is-broken seems relevant

iOS
Thanks to developer community feedback, we removed iOS from the list. This browser has known issues delivering on the promises of beacon API. The sendBeacon event itself is working, but the unload/beforeunload events are not fired. We should have used the pagehide and/or visibilitychange events instead.
Unfortunately we have no data how reliable iOS is when the data is sent on these mobile-specific events.

> So testing was not correct on iOS.

[Chris Dumez]

The only change in our Beacon implementation in Safari 13 I am aware of was this one:
https://bugs.webkit.org/show_bug.cgi?id=197919

Technically, if you exit Safari, the network process will go away and Beacon loads could get interrupted in this case if there are still pending. I guess using such a Low priority for beacon makes it more likely to happen and it could in theory explain the increase in failures.

I propose we revert Bug 197919.

[Chris Dumez]

Created attachment 386237 [details]
Patch

[Yoav Weiss]

(In reply to Chris Dumez from comment #3)
> (In reply to Yoav Weiss from comment #2)
> > https://volument.com/blog/sendbeacon-is-broken seems relevant
> 
> iOS
> Thanks to developer community feedback, we removed iOS from the list. This
> browser has known issues delivering on the promises of beacon API. The
> sendBeacon event itself is working, but the unload/beforeunload events are
> not fired. We should have used the pagehide and/or visibilitychange events
> instead.
> Unfortunately we have no data how reliable iOS is when the data is sent on
> these mobile-specific events.
> 
> > So testing was not correct on iOS.

Yup, my bad. The methodology of this blog post was indeed flawed. The other reports still stand though.

[WebKit Commit Bot]

The commit-queue encountered the following flaky tests while processing attachment 386237 [details]:

fetch/fetch-worker-crash.html bug 187257 (author: [e-mail])
The commit-queue is continuing to process your patch.

[WebKit Commit Bot]

Comment on attachment 386237 [details]
Patch

Clearing flags on attachment: 386237

Committed r253847: <https://trac.webkit.org/changeset/253847>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.