Replace SessionTracker with HashMap member of NetworkProcess
Created attachment 358652 [details] Patch
Created attachment 358659 [details] Patch
Created attachment 358664 [details] Patch
Comment on attachment 358664 [details] Patch Attachment 358664 [details] did not pass mac-wk2-ews (mac-wk2): Output: https://webkit-queues.webkit.org/results/10680306 Number of test failures exceeded the failure limit.
Created attachment 358672 [details] Archive of layout-test-results from ews104 for mac-sierra-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews104 Port: mac-sierra-wk2 Platform: Mac OS X 10.12.6
Comment on attachment 358664 [details] Patch Attachment 358664 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: https://webkit-queues.webkit.org/results/10680443 Number of test failures exceeded the failure limit.
Created attachment 358675 [details] Archive of layout-test-results from ews126 for ios-simulator-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews126 Port: ios-simulator-wk2 Platform: Mac OS X 10.13.6
Created attachment 358720 [details] Patch
Comment on attachment 358720 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=358720&action=review r=me > Source/WebKit/NetworkProcess/Downloads/DownloadManager.h:75 > + virtual NetworkSession* networkSession(const PAL::SessionID&) = 0; This looks like a getter, could be made const, but not really important.
Great idea! Done! http://trac.webkit.org/r239815
<rdar://problem/47167364>
Looks like https://trac.webkit.org/changeset/239815/webkit has caused http/tests/workers/service/serviceworker-private-browsing.https.html to become a consistent timeout. History: https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=http%2Ftests%2Fworkers%2Fservice%2Fserviceworker-private-browsing.https.html Reproduced with: run-webkit-tests --root testbuild-239815 http/tests/workers/service/serviceworker-private-browsing.https.html --iterations 50 -f I got a %50 timeout rate locally with r239815 and no timeouts on 239814
I'm looking into it
Fix is in https://bugs.webkit.org/show_bug.cgi?id=193325