RESOLVED FIXED 213291
Add support for fetching registrable domains with resource load statistics
https://bugs.webkit.org/show_bug.cgi?id=213291
Summary Add support for fetching registrable domains with resource load statistics
Carlos Garcia Campos
Reported 2020-06-17 07:09:49 PDT
WebsiteDataStore::fetchData() doesn't return anything for resource load statistics because NetworkProcess::fetchWebsiteData() doesn't handle WebsiteDataType::ResourceLoadStatistics
Attachments
Patch (20.35 KB, patch)
2020-06-17 07:19 PDT, Carlos Garcia Campos
aperez: review+
Patch for landing (20.22 KB, patch)
2020-06-18 06:24 PDT, Carlos Garcia Campos
no flags
Patch for landing (20.86 KB, patch)
2020-06-18 07:28 PDT, Carlos Garcia Campos
no flags
Carlos Garcia Campos
Comment 1 2020-06-17 07:19:15 PDT
John Wilander
Comment 2 2020-06-17 10:42:02 PDT
Comment on attachment 402105 [details] Patch Just as a general comment, we've struggled with the term website data here because ITP data isn't website data, i.e. it isn't data that the website creates but that WebKit creates *about* websites. That is in part why this has not been folded into the reporting structure.
Adrian Perez
Comment 3 2020-06-18 00:46:09 PDT
Comment on attachment 402105 [details] Patch Patch looks reasonable, but the API tests are failing. Could you take check that up, please?
Carlos Garcia Campos
Comment 4 2020-06-18 01:00:52 PDT
(In reply to John Wilander from comment #2) > Comment on attachment 402105 [details] > Patch > > Just as a general comment, we've struggled with the term website data here > because ITP data isn't website data, i.e. it isn't data that the website > creates but that WebKit creates *about* websites. That is in part why this > has not been folded into the reporting structure. I see. I still think it makes sense to allow the user to remove the resource load stats, like other (website) data and caches. In epiphany we always query the data before showing the option to remove it. In the case of itp data we don't know if there's data to remove. That's how I noticed this.
Carlos Garcia Campos
Comment 5 2020-06-18 01:04:09 PDT
(In reply to Adrian Perez from comment #3) > Comment on attachment 402105 [details] > Patch > > Patch looks reasonable, but the API tests are failing. Could you take > check that up, please? I'll check, tests pass for me locally. It might be flaky.
Carlos Garcia Campos
Comment 6 2020-06-18 01:08:50 PDT
The API test failure could also be because of bug #213290, if there are registrations in the default location in the system, I'll run EWS again after landing that patch.
Adrian Perez
Comment 7 2020-06-18 01:13:28 PDT
(In reply to Carlos Garcia Campos from comment #6) > The API test failure could also be because of bug #213290, if there are > registrations in the default location in the system, I'll run EWS again > after landing that patch. I suppose it would make sense to reset to a known state (in this case: remove all) at the beginning of the API tests, before doing checks :)
Adrian Perez
Comment 8 2020-06-18 01:15:56 PDT
Comment on attachment 402105 [details] Patch r=me, but let's please make sure the tests pass before landing :]
Carlos Garcia Campos
Comment 9 2020-06-18 01:21:01 PDT
(In reply to Adrian Perez from comment #8) > Comment on attachment 402105 [details] > Patch > > r=me, but let's please make sure the tests pass before landing :] Sure, I'll also wait for WebKit2 owners to confirm they are ok with this change.
Adrian Perez
Comment 10 2020-06-18 01:22:23 PDT
(In reply to Carlos Garcia Campos from comment #9) > (In reply to Adrian Perez from comment #8) > > Comment on attachment 402105 [details] > > Patch > > > > r=me, but let's please make sure the tests pass before landing :] > > Sure, I'll also wait for WebKit2 owners to confirm they are ok with this > change. Perfect, thanks!
youenn fablet
Comment 11 2020-06-18 02:16:52 PDT
Comment on attachment 402105 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=402105&action=review > Source/WebKit/NetworkProcess/Classifier/ResourceLoadStatisticsDatabaseStore.h:147 > + Vector<RegistrableDomain> allDomains() const override; final? > Source/WebKit/NetworkProcess/Classifier/ResourceLoadStatisticsMemoryStore.h:116 > + Vector<RegistrableDomain> allDomains() const override; final? > Source/WebKit/NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp:1375 > + postTaskReply([domains = WTFMove(domains), completionHandler = WTFMove(completionHandler)]() mutable { Hopping to another thread, this requires isolatedCopying domains. > Source/WebKit/NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp:1378 > + }); Can we write it with a ternary, something like: auto domains = m_statisticsStore ? m_statisticsStore->allDomains() : { }; postTaskReply([domains = crossThreadCopy(WTFMove(domains)), completionHandler = WTFMove(completionHandler)]() mutable { completionHandler(WTFMove(domains)); }); > Source/WebKit/NetworkProcess/NetworkProcess.cpp:1586 > + resourceLoadStatistics->registrableDomains([callbackAggregator = callbackAggregator.copyRef()](Vector<RegistrableDomain>&& domains) mutable { s/Vector<RegistrableDomain>/auto
youenn fablet
Comment 12 2020-06-18 02:18:33 PDT
LGTM though I'd like to understand John comment more. (In reply to John Wilander from comment #2) > Comment on attachment 402105 [details] > Patch > > Just as a general comment, we've struggled with the term website data here > because ITP data isn't website data, i.e. it isn't data that the website > creates but that WebKit creates *about* websites. That is in part why this > has not been folded into the reporting structure. It seems good to have a way to retrieve that information. I guess your suggestion might be that the UI might be different and maybe the API should be different from other website data?
Carlos Garcia Campos
Comment 13 2020-06-18 05:58:42 PDT
(In reply to youenn fablet from comment #11) > Comment on attachment 402105 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=402105&action=review > > > Source/WebKit/NetworkProcess/Classifier/ResourceLoadStatisticsDatabaseStore.h:147 > > + Vector<RegistrableDomain> allDomains() const override; > > final? > > > Source/WebKit/NetworkProcess/Classifier/ResourceLoadStatisticsMemoryStore.h:116 > > + Vector<RegistrableDomain> allDomains() const override; > > final? > > > Source/WebKit/NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp:1375 > > + postTaskReply([domains = WTFMove(domains), completionHandler = WTFMove(completionHandler)]() mutable { > > Hopping to another thread, this requires isolatedCopying domains. Also when moving? > > Source/WebKit/NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp:1378 > > + }); > > Can we write it with a ternary, something like: > auto domains = m_statisticsStore ? m_statisticsStore->allDomains() : { }; > postTaskReply([domains = crossThreadCopy(WTFMove(domains)), > completionHandler = WTFMove(completionHandler)]() mutable { > completionHandler(WTFMove(domains)); > }); Yes, I started with something like this but then I decided to follow what other similar methods in the file were doing. > > Source/WebKit/NetworkProcess/NetworkProcess.cpp:1586 > > + resourceLoadStatistics->registrableDomains([callbackAggregator = callbackAggregator.copyRef()](Vector<RegistrableDomain>&& domains) mutable { > > s/Vector<RegistrableDomain>/auto
youenn fablet
Comment 14 2020-06-18 06:07:52 PDT
> > > Source/WebKit/NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp:1375 > > > + postTaskReply([domains = WTFMove(domains), completionHandler = WTFMove(completionHandler)]() mutable { > > > > Hopping to another thread, this requires isolatedCopying domains. > > Also when moving? Yes, moving will only prevent refing when capturing. It is safe to hop to another thread with a String which counter is 1. But otherwise, like in the in memory case, the strings may be derefed in both threads. There is no guarantee that this will be the case in your code (especially for in memory stores). Also isolatedCopy tries to optimise the case of Strings that are moved and which counter is 1, see String String::isolatedCopy() &&. We could try to optimise the case of a Vector<T>&& so as to reuse the allocated vector and call isolatedCopy() && on each item as well.
Carlos Garcia Campos
Comment 15 2020-06-18 06:24:25 PDT
Created attachment 402202 [details] Patch for landing
Carlos Garcia Campos
Comment 16 2020-06-18 07:28:53 PDT
Created attachment 402206 [details] Patch for landing
Carlos Garcia Campos
Comment 17 2020-06-19 00:49:31 PDT
Radar WebKit Bug Importer
Comment 18 2020-06-19 00:50:21 PDT
Note You need to log in before you can comment on or make changes to this bug.