Bug 231070 - Implement https://w3c.github.io/push-api/#receiving-a-push-message
Summary: Implement https://w3c.github.io/push-api/#receiving-a-push-message
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Service Workers (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: youenn fablet
URL:
Keywords: InRadar
Depends on: 231008
Blocks:
  Show dependency treegraph
 
Reported: 2021-10-01 03:38 PDT by youenn fablet
Modified: 2021-10-06 07:11 PDT (History)
8 users (show)

See Also:


Attachments
Patch (31.63 KB, patch)
2021-10-01 03:44 PDT, youenn fablet
no flags Details | Formatted Diff | Diff
Patch (31.80 KB, patch)
2021-10-03 01:22 PDT, youenn fablet
no flags Details | Formatted Diff | Diff
Patch for landing (31.71 KB, patch)
2021-10-06 00:40 PDT, youenn fablet
no flags Details | Formatted Diff | Diff
Rebasing (31.87 KB, patch)
2021-10-06 03:14 PDT, youenn fablet
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description youenn fablet 2021-10-01 03:38:29 PDT
Implement https://w3c.github.io/push-api/#receiving-a-push-message
Comment 1 Radar WebKit Bug Importer 2021-10-01 03:38:54 PDT
<rdar://problem/83759574>
Comment 2 youenn fablet 2021-10-01 03:44:28 PDT
Created attachment 439838 [details]
Patch
Comment 3 youenn fablet 2021-10-03 01:22:58 PDT
Created attachment 439999 [details]
Patch
Comment 4 youenn fablet 2021-10-05 03:37:53 PDT
Ping review
Comment 5 Chris Dumez 2021-10-05 07:21:52 PDT
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.
Comment 6 youenn fablet 2021-10-06 00:36:35 PDT
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.
Comment 7 youenn fablet 2021-10-06 00:40:29 PDT
Created attachment 440342 [details]
Patch for landing
Comment 8 youenn fablet 2021-10-06 03:14:55 PDT
Created attachment 440350 [details]
Rebasing
Comment 9 EWS 2021-10-06 04:26:41 PDT
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].
Comment 10 Chris Dumez 2021-10-06 07:11:25 PDT
(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.