Summary: | Start of support for multiple WebsiteDataStore/SessionIDs per process | ||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Brady Eidson <beidson> | ||||||||||||||||||||||||
Component: | WebKit2 | Assignee: | Brady Eidson <beidson> | ||||||||||||||||||||||||
Status: | RESOLVED FIXED | ||||||||||||||||||||||||||
Severity: | Normal | CC: | achristensen, ap, berto, buildbot, cgarcia, commit-queue, ggaren, gustavo, mcatanzaro, ryanhaddad | ||||||||||||||||||||||||
Priority: | P2 | ||||||||||||||||||||||||||
Version: | WebKit Nightly Build | ||||||||||||||||||||||||||
Hardware: | Unspecified | ||||||||||||||||||||||||||
OS: | Unspecified | ||||||||||||||||||||||||||
See Also: | https://bugs.webkit.org/show_bug.cgi?id=171513 | ||||||||||||||||||||||||||
Attachments: |
|
Description
Brady Eidson
2017-04-28 00:54:18 PDT
Created attachment 308508 [details]
Preliminary patch
No ChangeLogs because this isn't quite ready to land (testing things locally), but review can start!
Comment on attachment 308508 [details] Preliminary patch View in context: https://bugs.webkit.org/attachment.cgi?id=308508&action=review We should make a test that makes a WKWebView with a persistent cookie storage at a known location, close the WKWebView and destroy the session, then make another WKWebView with a persistent cookie storage at the same known location and make sure that the cookies are there. I could imagine some problems with closing cookie storages that such a test would help prevent. > Source/WebKit2/UIProcess/WebsiteData/Cocoa/WebsiteDataStoreCocoa.mm:71 > +#if PLATFORM(IOS) Why only iOS and not Mac? > Source/WebKit2/WebProcess/WebCoreSupport/mac/WebFrameNetworkingContext.mm:86 > +#if PLATFORM(MAC) && __MAC_OS_X_VERSION_MIN_REQUIRED >= 101100 Why only Mac and not iOS? > Source/WebKit2/WebProcess/WebProcess.cpp:521 > +void WebProcess::destroySessionOrWebsiteDataStore(SessionID sessionID) I think destroySession would be a better name. Comment on attachment 308508 [details] Preliminary patch Attachment 308508 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/3625056 New failing tests: imported/w3c/web-platform-tests/html/semantics/tabular-data/processing-model-1/span-limits.html Created attachment 308512 [details]
Archive of layout-test-results from ews112 for mac-elcapitan
The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews112 Port: mac-elcapitan Platform: Mac OS X 10.11.6
(In reply to Alex Christensen from comment #2) > Comment on attachment 308508 [details] > Preliminary patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=308508&action=review > > We should make a test that makes a WKWebView with a persistent cookie > storage at a known location, close the WKWebView and destroy the session, > then make another WKWebView with a persistent cookie storage at the same > known location and make sure that the cookies are there. I could imagine > some problems with closing cookie storages that such a test would help > prevent. > > > Source/WebKit2/UIProcess/WebsiteData/Cocoa/WebsiteDataStoreCocoa.mm:71 > > +#if PLATFORM(IOS) > > Why only iOS and not Mac? Per NetworkProcessCreationParameters and WebProcessCreationParameters, we currently only need sandbox handle for the cookie path on iOS. > > Source/WebKit2/WebProcess/WebCoreSupport/mac/WebFrameNetworkingContext.mm:86 > > +#if PLATFORM(MAC) && __MAC_OS_X_VERSION_MIN_REQUIRED >= 101100 > > Why only Mac and not iOS? Per NetworkProcessCreationParameters and WebProcessCreationParameters, we currently only need the identifying data on Mac > > Source/WebKit2/WebProcess/WebProcess.cpp:521 > > +void WebProcess::destroySessionOrWebsiteDataStore(SessionID sessionID) > > I think destroySession would be a better name. K. Created attachment 308538 [details]
Patch
Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API Attachment 308538 [details] did not pass style-queue:
ERROR: Source/WebCore/ChangeLog:8: You should remove the 'No new tests' and either add and list tests, or explain why no new tests were possible. [changelog/nonewtests] [5]
Total errors found: 1 in 30 files
If any of these errors are false positives, please file a bug against check-webkit-style.
Created attachment 308540 [details]
Patch
Created attachment 308542 [details]
Patch
Created attachment 308552 [details]
Patch
Comment on attachment 308552 [details]
Patch
r=me
Created attachment 308555 [details]
Patch
Created attachment 308561 [details]
Patch
Created attachment 308562 [details]
Patch
Created attachment 308587 [details]
Patch
Comment on attachment 308587 [details] Patch Rejecting attachment 308587 [details] from commit-queue. Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-03', 'validate-changelog', '--check-oops', '--non-interactive', 308587, '--port=mac']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit ChangeLog entry in Tools/ChangeLog contains OOPS!. Full output: http://webkit-queues.webkit.org/results/3628567 Created attachment 308588 [details]
Patch
Comment on attachment 308588 [details] Patch Clearing flags on attachment: 308588 Committed r215941: <http://trac.webkit.org/changeset/215941> All reviewed patches have been landed. Closing bug. I suspect that this broke all perf tests: https://build.webkit.org/builders/Apple%20El%20Capitan%20Release%20WK2%20%28Perf%29/builds/296/steps/perf-test/logs/stdio This also caused an API test failure on ios-simulator: https://bugs.webkit.org/show_bug.cgi?id=171513 |