[webkit-reviews] review granted: [Bug 175007] Add initial support for navigator.sendBeacon : [Attachment 316903] Patch

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Aug 1 17:20:28 PDT 2017


Sam Weinig <sam at webkit.org> has granted Chris Dumez <cdumez at apple.com>'s
request for review:
Bug 175007: Add initial support for navigator.sendBeacon
https://bugs.webkit.org/show_bug.cgi?id=175007

Attachment 316903: Patch

https://bugs.webkit.org/attachment.cgi?id=316903&action=review




--- Comment #16 from Sam Weinig <sam at webkit.org> ---
Comment on attachment 316903
  --> https://bugs.webkit.org/attachment.cgi?id=316903
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=316903&action=review

> Source/WebCore/Modules/beacon/NavigatorBeacon.cpp:44
> +	   return Exception { TypeError, ASCIILiteral("Beacons can only be sent
over HTTP(S)") };

Do we use the "HTTP(S)" in other exception text, or anywhere else?

> Source/WebCore/Modules/beacon/NavigatorBeacon.cpp:47
> +    // We do not allow sending beacons from detached documents.

This should either explain why or be removed.

> Source/WebCore/loader/PingLoader.cpp:272
> +    startPingLoad(frame, request, ShouldFollowRedirects::Yes);

What happens to a ping load that wants to follow redirects when the page is
closed? Does the NetworkProcess handle this without consulting the WebProcess?
What does that mean for content extensions that would like to block some of
those redirects?

> Source/WebCore/loader/PingLoader.h:62
> +using BodyInit = Variant<RefPtr<Blob>, RefPtr<JSC::ArrayBufferView>,
RefPtr<JSC::ArrayBuffer>, RefPtr<DOMFormData>, RefPtr<URLSearchParams>,
String>;

At some point we should put this in a header.  You can use FetchBody::Init,
which should be the same.

> Tools/WebKitTestRunner/InjectedBundle/InjectedBundle.cpp:349
> +    m_testRunner->setBeaconAPIEnabled(true);

Why not enable this in the normal preferences? Why use the weird ones in the
bundle?


More information about the webkit-reviews mailing list