RESOLVED FIXED211520
ResourceLoadStatistics data summary call should create a web process pool if one doesn't exist
https://bugs.webkit.org/show_bug.cgi?id=211520
Summary ResourceLoadStatistics data summary call should create a web process pool if ...
Kate Cheney
Reported 2020-05-06 11:02:47 PDT
This call should be available even if a web process pool doesn't already exist.
Attachments
Patch (19.36 KB, patch)
2020-05-06 11:15 PDT, Kate Cheney
no flags
Patch (16.62 KB, patch)
2020-05-06 12:24 PDT, Kate Cheney
no flags
Patch (15.53 KB, patch)
2020-05-06 12:52 PDT, Kate Cheney
no flags
Kate Cheney
Comment 1 2020-05-06 11:03:01 PDT
Kate Cheney
Comment 2 2020-05-06 11:15:44 PDT
Chris Dumez
Comment 3 2020-05-06 11:42:13 PDT
Comment on attachment 398639 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=398639&action=review > Source/WebKit/UIProcess/API/Cocoa/WKWebsiteDataStorePrivate.h:82 > +- (void)_hasProcessPool:(void (^)(BOOL))completionHandler WK_API_AVAILABLE(macos(WK_MAC_TBA), ios(WK_IOS_TBA)); This does not need to be asynchronous or take a completion handler in. > Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.cpp:1543 > + for (auto& processPool : ensureProcessPools()) { ensureProcessPools() does NOT create a persistent process pool. As soon as this loop is over, the process pool that was created should get destroyed (unless some other object is ref'ing it). As a result, I am perplexed by your new hasProcessPool getter and testing.
Kate Cheney
Comment 4 2020-05-06 12:01:02 PDT
(In reply to Chris Dumez from comment #3) > Comment on attachment 398639 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=398639&action=review > > > Source/WebKit/UIProcess/API/Cocoa/WKWebsiteDataStorePrivate.h:82 > > +- (void)_hasProcessPool:(void (^)(BOOL))completionHandler WK_API_AVAILABLE(macos(WK_MAC_TBA), ios(WK_IOS_TBA)); > > This does not need to be asynchronous or take a completion handler in. > > > Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.cpp:1543 > > + for (auto& processPool : ensureProcessPools()) { > > ensureProcessPools() does NOT create a persistent process pool. As soon as > this loop is over, the process pool that was created should get destroyed > (unless some other object is ref'ing it). > > As a result, I am perplexed by your new hasProcessPool getter and testing. I am only using the getter to confirm that the test is setup correctly before calling the API. It should have no existing process pools to start with.
Chris Dumez
Comment 5 2020-05-06 12:09:20 PDT
(In reply to katherine_cheney from comment #4) > (In reply to Chris Dumez from comment #3) > > Comment on attachment 398639 [details] > > Patch > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=398639&action=review > > > > > Source/WebKit/UIProcess/API/Cocoa/WKWebsiteDataStorePrivate.h:82 > > > +- (void)_hasProcessPool:(void (^)(BOOL))completionHandler WK_API_AVAILABLE(macos(WK_MAC_TBA), ios(WK_IOS_TBA)); > > > > This does not need to be asynchronous or take a completion handler in. > > > > > Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.cpp:1543 > > > + for (auto& processPool : ensureProcessPools()) { > > > > ensureProcessPools() does NOT create a persistent process pool. As soon as > > this loop is over, the process pool that was created should get destroyed > > (unless some other object is ref'ing it). > > > > As a result, I am perplexed by your new hasProcessPool getter and testing. > > I am only using the getter to confirm that the test is setup correctly > before calling the API. It should have no existing process pools to start > with. I see. Then I think it may be overkill to add a new SPI just to check that your API test did not create a process pool.
Kate Cheney
Comment 6 2020-05-06 12:24:27 PDT
(In reply to Chris Dumez from comment #5) > (In reply to katherine_cheney from comment #4) > > (In reply to Chris Dumez from comment #3) > > > Comment on attachment 398639 [details] > > > Patch > > > > > > View in context: > > > https://bugs.webkit.org/attachment.cgi?id=398639&action=review > > > > > > > Source/WebKit/UIProcess/API/Cocoa/WKWebsiteDataStorePrivate.h:82 > > > > +- (void)_hasProcessPool:(void (^)(BOOL))completionHandler WK_API_AVAILABLE(macos(WK_MAC_TBA), ios(WK_IOS_TBA)); > > > > > > This does not need to be asynchronous or take a completion handler in. > > > > > > > Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.cpp:1543 > > > > + for (auto& processPool : ensureProcessPools()) { > > > > > > ensureProcessPools() does NOT create a persistent process pool. As soon as > > > this loop is over, the process pool that was created should get destroyed > > > (unless some other object is ref'ing it). > > > > > > As a result, I am perplexed by your new hasProcessPool getter and testing. > > > > I am only using the getter to confirm that the test is setup correctly > > before calling the API. It should have no existing process pools to start > > with. > > I see. Then I think it may be overkill to add a new SPI just to check that > your API test did not create a process pool. Got it. I was just trying to be thorough :)
Kate Cheney
Comment 7 2020-05-06 12:24:48 PDT
Chris Dumez
Comment 8 2020-05-06 12:27:38 PDT
Comment on attachment 398645 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=398645&action=review Ok if bots are happy. > Source/WebKit/UIProcess/API/Cocoa/WKWebsiteDataStorePrivate.h:-82 > - Unnecessary change.
Kate Cheney
Comment 9 2020-05-06 12:52:49 PDT
Kate Cheney
Comment 10 2020-05-06 12:53:22 PDT
(In reply to Chris Dumez from comment #8) > Comment on attachment 398645 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=398645&action=review > > Ok if bots are happy. > > > Source/WebKit/UIProcess/API/Cocoa/WKWebsiteDataStorePrivate.h:-82 > > - > > Unnecessary change. Thanks! Waiting for bots before I cq+
EWS
Comment 11 2020-05-06 13:59:46 PDT
Committed r261250: <https://trac.webkit.org/changeset/261250> All reviewed patches have been landed. Closing bug and clearing flags on attachment 398647 [details].
Note You need to log in before you can comment on or make changes to this bug.