RESOLVED FIXED 190687
Only cap lifetime of persistent cookies created client-side through document.cookie when resource load statistics is enabled
https://bugs.webkit.org/show_bug.cgi?id=190687
Summary Only cap lifetime of persistent cookies created client-side through document....
John Wilander
Reported 2018-10-17 13:33:15 PDT
We should restrict the change in https://bugs.webkit.org/show_bug.cgi?id=189933 to when resource load statistics is enabled.
Attachments
Patch (37.24 KB, patch)
2018-10-17 13:59 PDT, John Wilander
no flags
Patch (37.29 KB, patch)
2018-10-17 14:11 PDT, John Wilander
no flags
Patch (37.30 KB, patch)
2018-10-17 15:44 PDT, John Wilander
no flags
Patch (57.60 KB, patch)
2018-10-18 17:35 PDT, John Wilander
no flags
Archive of layout-test-results from ews106 for mac-sierra-wk2 (3.23 MB, application/zip)
2018-10-18 18:39 PDT, EWS Watchlist
no flags
Archive of layout-test-results from ews124 for ios-simulator-wk2 (2.56 MB, application/zip)
2018-10-18 21:44 PDT, EWS Watchlist
no flags
Archive of layout-test-results from ews122 for ios-simulator-wk2 (2.87 MB, application/zip)
2018-10-18 23:29 PDT, EWS Watchlist
no flags
Patch (61.14 KB, patch)
2018-10-19 11:11 PDT, John Wilander
no flags
Radar WebKit Bug Importer
Comment 1 2018-10-17 13:36:53 PDT
John Wilander
Comment 2 2018-10-17 13:59:12 PDT
John Wilander
Comment 3 2018-10-17 14:11:41 PDT
Chris Dumez
Comment 4 2018-10-17 15:41:12 PDT
Regressions: Unexpected text-only failures (1) http/tests/resourceLoadStatistics/capped-lifetime-for-cookie-set-in-js.html [ Failure ]
John Wilander
Comment 5 2018-10-17 15:43:39 PDT
(In reply to Chris Dumez from comment #4) > Regressions: Unexpected text-only failures (1) > > http/tests/resourceLoadStatistics/capped-lifetime-for-cookie-set-in-js.html > [ Failure ] I moved the test last thing and forgot to update the relative path to cookie-utilities.js. :( New patch coming.
John Wilander
Comment 6 2018-10-17 15:44:37 PDT
Chris Dumez
Comment 7 2018-10-18 08:54:17 PDT
Comment on attachment 352654 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=352654&action=review > Source/WebKit/UIProcess/WebResourceLoadStatisticsStore.cpp:213 > + if (m_networkProcessCreated) Which network process? The current models is that a single WebsiteDataStore / WebResourceLoadStatisticsStore can be associated with several WebProcessPools and thus several network processes. As a result, this design relying on a single m_networkProcessCreated flag does not seem to make much sense. > Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.cpp:1273 > + for (auto& processPool : processPools()) { See how you're iterating over several process pools here? That's right since a single WebsiteDataStore can be associated with several process pools.
John Wilander
Comment 8 2018-10-18 12:05:41 PDT
(In reply to Chris Dumez from comment #7) > Comment on attachment 352654 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=352654&action=review > > > Source/WebKit/UIProcess/WebResourceLoadStatisticsStore.cpp:213 > > + if (m_networkProcessCreated) > > Which network process? The current models is that a single WebsiteDataStore > / WebResourceLoadStatisticsStore can be associated with several > WebProcessPools and thus several network processes. > As a result, this design relying on a single m_networkProcessCreated flag > does not seem to make much sense. I see. It may be mostly a naming thing, i.e. the boolean is saying "the first network process has been created so it makes sense to send it data." But what I need to do is to think through how things are marked as "has already been sent to the network process." That's existing code that assumes that all network processes existed when the message went out. Maybe that state doesn't make sense and we should always send the complete set to all network processes. > > Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.cpp:1273 > > + for (auto& processPool : processPools()) { > > See how you're iterating over several process pools here? That's right since > a single WebsiteDataStore can be associated with several process pools. I think this part is OK. ITP doesn't know how many network processes there are. It only needs to know that the first one has been created. I will go through the code to see how this can make better sense.
John Wilander
Comment 9 2018-10-18 17:35:26 PDT
John Wilander
Comment 10 2018-10-18 18:29:47 PDT
Test failures seem to be text diff output because of the removal of the in-memory-only state.
EWS Watchlist
Comment 11 2018-10-18 18:39:07 PDT
Comment on attachment 352751 [details] Patch Attachment 352751 [details] did not pass mac-wk2-ews (mac-wk2): Output: https://webkit-queues.webkit.org/results/9657774 New failing tests: http/tests/webAPIStatistics/font-load-data-collection.html http/tests/webAPIStatistics/canvas-read-and-write-data-collection.html http/tests/webAPIStatistics/navigator-functions-accessed-data-collection.html http/tests/webAPIStatistics/screen-functions-accessed-data-collection.html
EWS Watchlist
Comment 12 2018-10-18 18:39:09 PDT
Created attachment 352753 [details] Archive of layout-test-results from ews106 for mac-sierra-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews106 Port: mac-sierra-wk2 Platform: Mac OS X 10.12.6
EWS Watchlist
Comment 13 2018-10-18 21:44:36 PDT
Comment on attachment 352751 [details] Patch Attachment 352751 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: https://webkit-queues.webkit.org/results/9659204 New failing tests: http/tests/webAPIStatistics/font-load-data-collection.html http/tests/webAPIStatistics/canvas-read-and-write-data-collection.html http/tests/webAPIStatistics/navigator-functions-accessed-data-collection.html http/tests/webAPIStatistics/screen-functions-accessed-data-collection.html
EWS Watchlist
Comment 14 2018-10-18 21:44:38 PDT
Created attachment 352765 [details] Archive of layout-test-results from ews124 for ios-simulator-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews124 Port: ios-simulator-wk2 Platform: Mac OS X 10.13.6
EWS Watchlist
Comment 15 2018-10-18 23:29:00 PDT
Comment on attachment 352751 [details] Patch Attachment 352751 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: https://webkit-queues.webkit.org/results/9660495 New failing tests: http/tests/webAPIStatistics/font-load-data-collection.html http/tests/webAPIStatistics/canvas-read-and-write-data-collection.html http/tests/webAPIStatistics/navigator-functions-accessed-data-collection.html http/tests/webAPIStatistics/screen-functions-accessed-data-collection.html
EWS Watchlist
Comment 16 2018-10-18 23:29:02 PDT
Created attachment 352771 [details] Archive of layout-test-results from ews122 for ios-simulator-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews122 Port: ios-simulator-wk2 Platform: Mac OS X 10.13.6
John Wilander
Comment 17 2018-10-19 11:11:54 PDT
John Wilander
Comment 18 2018-10-19 14:12:45 PDT
Comment on attachment 352804 [details] Patch Thanks, Alex (and Chris)!
WebKit Commit Bot
Comment 19 2018-10-19 14:38:02 PDT
Comment on attachment 352804 [details] Patch Clearing flags on attachment: 352804 Committed r237304: <https://trac.webkit.org/changeset/237304>
WebKit Commit Bot
Comment 20 2018-10-19 14:38:04 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.