RESOLVED FIXED Bug 231070
Implement https://w3c.github.io/push-api/#receiving-a-push-message
https://bugs.webkit.org/show_bug.cgi?id=231070
Summary Implement https://w3c.github.io/push-api/#receiving-a-push-message
youenn fablet
Reported 2021-10-01 03:38:29 PDT
Attachments
Patch (31.63 KB, patch)
2021-10-01 03:44 PDT, youenn fablet
no flags
Patch (31.80 KB, patch)
2021-10-03 01:22 PDT, youenn fablet
no flags
Patch for landing (31.71 KB, patch)
2021-10-06 00:40 PDT, youenn fablet
no flags
Rebasing (31.87 KB, patch)
2021-10-06 03:14 PDT, youenn fablet
no flags
Radar WebKit Bug Importer
Comment 1 2021-10-01 03:38:54 PDT
youenn fablet
Comment 2 2021-10-01 03:44:28 PDT
youenn fablet
Comment 3 2021-10-03 01:22:58 PDT
youenn fablet
Comment 4 2021-10-05 03:37:53 PDT
Ping review
Chris Dumez
Comment 5 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.
youenn fablet
Comment 6 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.
youenn fablet
Comment 7 2021-10-06 00:40:29 PDT
Created attachment 440342 [details] Patch for landing
youenn fablet
Comment 8 2021-10-06 03:14:55 PDT
Created attachment 440350 [details] Rebasing
EWS
Comment 9 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].
Chris Dumez
Comment 10 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.
Note You need to log in before you can comment on or make changes to this bug.