Bug 231070 – Implement https://w3c.github.io/push-api/#receiving-a-push-message

• Status: RESOLVED
• Resolution: FIXED
• Component: Service Workers

[youenn fablet]

Implement https://w3c.github.io/push-api/#receiving-a-push-message

[Radar WebKit Bug Importer]

<rdar://problem/83759574>

[youenn fablet]

Created attachment 439838 [details]
Patch

[youenn fablet]

Created attachment 439999 [details]
Patch

[youenn fablet]

Ping review

[Chris Dumez]

Comment on attachment 439999 [details]
Patch

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

> Source/WebCore/workers/service/server/SWServer.h:225
> +    enum class ShouldSkipEvent { No, Yes };

: bool

> Source/WebKit/NetworkProcess/NetworkProcess.cpp:2539
> +        data = Vector<uint8_t> { ipcData->data(), ipcData->size()  };

nit: extra space before }

> Source/WebKit/NetworkProcess/NetworkProcess.h:400
> +    void processPushMessage(PAL::SessionID, const std::optional<IPC::DataReference>&, URL&&, CompletionHandler<void(bool)>&&);

Would be good to not omit the bool parameter name as it is not obvious.

> Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerToContextConnection.cpp:110
> +void WebSWServerToContextConnection::firePushEvent(WebCore::ServiceWorkerIdentifier serviceWorkerIdentifier, const std::optional<Vector<uint8_t>>& data, CompletionHandler<void(bool)>&& callback)

Would be good to not omit the bool parameter name as it is not obvious.

> Source/WebKit/UIProcess/API/Cocoa/WKWebsiteDataStore.mm:756
> +        data = Span<const uint8_t> { reinterpret_cast<const uint8_t*>(message.bytes), message.length };

It doesn't look safe to wrap the provided NSData into a Span and do stuff asynchronously. The lifetime of the NSData* is controller by the caller (client) and it may be destroyed right after this call, leaving your Span invalid.
We should be using a SharedBuffer, not a Span IMO. A SharedBuffer can wrap a NSData and does not actually copy the data either.

The current code might be safe depending on how long you hold on to the Span but it is fragile at best.

> Source/WebKit/UIProcess/API/Cocoa/WKWebsiteDataStorePrivate.h:108
> +-(void)_processPushMessage:(NSData*) data registration:(NSURL *)registration completionHandler:(void(^)(bool))completionHandler WK_API_AVAILABLE(macos(WK_MAC_TBA), ios(WK_IOS_TBA));

nit: extra space before data.

> Tools/TestWebKitAPI/Tests/WebKitCocoa/PushAPI.mm:126
> +    done = false;

duplicate statement.

[youenn fablet]

Thanks, will update accordingly.

> > Source/WebKit/UIProcess/API/Cocoa/WKWebsiteDataStore.mm:756
> > +        data = Span<const uint8_t> { reinterpret_cast<const uint8_t*>(message.bytes), message.length };
> 
> It doesn't look safe to wrap the provided NSData into a Span and do stuff
> asynchronously. The lifetime of the NSData* is controller by the caller
> (client) and it may be destroyed right after this call, leaving your Span
> invalid.
> We should be using a SharedBuffer, not a Span IMO. A SharedBuffer can wrap a
> NSData and does not actually copy the data either.
> 
> The current code might be safe depending on how long you hold on to the Span
> but it is fragile at best.

I think the assumption with Span<const uint8_t> is that it must be used synchronously.
I can pass a const uint8_t*/size_t set of parameters if that is clearer.

[youenn fablet]

Created attachment 440342 [details]
Patch for landing

[youenn fablet]

Created attachment 440350 [details]
Rebasing

[EWS]

Committed r283613 (242565@main): <https://commits.webkit.org/242565@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 440350 [details].

[Chris Dumez]

(In reply to youenn fablet from comment #6)
> Thanks, will update accordingly.
> 
> > > Source/WebKit/UIProcess/API/Cocoa/WKWebsiteDataStore.mm:756
> > > +        data = Span<const uint8_t> { reinterpret_cast<const uint8_t*>(message.bytes), message.length };
> > 
> > It doesn't look safe to wrap the provided NSData into a Span and do stuff
> > asynchronously. The lifetime of the NSData* is controller by the caller
> > (client) and it may be destroyed right after this call, leaving your Span
> > invalid.
> > We should be using a SharedBuffer, not a Span IMO. A SharedBuffer can wrap a
> > NSData and does not actually copy the data either.
> > 
> > The current code might be safe depending on how long you hold on to the Span
> > but it is fragile at best.
> 
> I think the assumption with Span<const uint8_t> is that it must be used
> synchronously.
> I can pass a const uint8_t*/size_t set of parameters if that is clearer.

A SharedBuffer has zero cost and is a safer type.