62662 2011-06-14 13:47:15 -0700 inspector/cookie-parser.html is a flaky crash 2014-12-12 14:09:04 -0800 1 1 1 Unclassified WebKit Web Inspector (Deprecated) 528+ (Nightly build) All All RESOLVED INVALID P2 Normal --- 79668 1 webkit.review.bot pfeldman abarth abecsi caseq dglazkov kbalazs kkristof ossy vsevik oldest_to_newest 420709 0 webkit.review.bot 2011-06-14 13:47:15 -0700 [Chromium] inspector/cookie-parser.html is a flaky crash Requested by dglazkov on #webkit. 420710 1 dglazkov 2011-06-14 13:47:46 -0700 http://test-results.appspot.com/dashboards/flakiness_dashboard.html#group=%40ToT%20-%20chromium.org&tests=inspector%2Fcookie-parser.html 420737 2 abarth 2011-06-14 14:45:06 -0700 Dare I ask why the inspector has a cookie parser? 421024 3 pfeldman 2011-06-14 22:49:00 -0700 (In reply to comment #2) > Dare I ask why the inspector has a cookie parser? 421030 4 pfeldman 2011-06-14 23:00:10 -0700 > (In reply to comment #2) > > Dare I ask why the inspector has a cookie parser? Feature: Show Cookies and Set-Cookie per request Cookie parsing is a part of the browser / network stack, i.e. platform-specific. None of the platforms expose APIs for parsing the cookies (Set-Cookie in particular). It often is encapsulated in the network stack. So the options are a) - expose parsing APIs on platforms (not always possible) - extend WebKit API to include parsed structures (no super good reason for that) - extend Web Inspector protocol to accompany raw headers with parsed structures (also not such a good reason to increase API surface) b) - check whether cookie parsing is conservative enough and do a 100 line snippet with good enough quality that would do that for us (b) it is. 421045 5 abarth 2011-06-14 23:28:02 -0700 Hopefully we use this parsing algorithm: http://tools.ietf.org/html/rfc6265#section-5.2 :) 421057 6 pfeldman 2011-06-14 23:37:39 -0700 (In reply to comment #5) > Hopefully we use this parsing algorithm: > http://tools.ietf.org/html/rfc6265#section-5.2 > :) I think caseq@ ported it from Chromium with its deviations from the RFCs accepted by Mozilla and IE. 421061 7 abarth 2011-06-14 23:49:09 -0700 > I think caseq@ ported it from Chromium with its deviations from the RFCs accepted by Mozilla and IE. There shouldn't be any deviations from RFC 6265. (That's the whole point of that spec.) We're cleaning up any deviations that we discover to match that spec precisely. If you know of any deviations, please let me know. 421065 8 pfeldman 2011-06-14 23:55:22 -0700 > There shouldn't be any deviations from RFC 6265. (That's the whole point of that spec.) We're cleaning up any deviations that we discover to match that spec precisely. If you know of any deviations, please let me know. Oh, I was not familiar with the effort. I implied deviations from the old 2109/2965. Things like http://codesearch.google.com/#OAMlx_jo-ck/src/net/base/cookie_monster.cc&exact_package=chromium&q=offer%5Csan%5Csoption%5Csfor%5Csquoted&l=1829. We'll probably need to sync our port once the cleanup is complete. 421068 9 abarth 2011-06-14 23:58:15 -0700 > Oh, I was not familiar with the effort. I implied deviations from the old 2109/2965. Yes. Those specs are not related to reality. > Things like http://codesearch.google.com/#OAMlx_jo-ck/src/net/base/cookie_monster.cc&exact_package=chromium&q=offer%5Csan%5Csoption%5Csfor%5Csquoted&l=1829. It's now clear how quoted strings should be handled. I personally changed Firefox to match IE, Chrome, and RFC 6265. Paul has promised to change CFNetwork to match as well. 421073 10 abarth 2011-06-15 00:05:22 -0700 I've posted http://codereview.chromium.org/7155016 to remove these out-of-date and confusing comments. 421083 11 pfeldman 2011-06-15 00:32:27 -0700 (In reply to comment #10) > I've posted http://codereview.chromium.org/7155016 to remove these out-of-date and confusing comments. Filed https://bugs.webkit.org/show_bug.cgi?id=62700 on inspector requiring its validation against the new rfc. 434737 12 ossy 2011-07-11 03:31:44 -0700 It isn't Chromium specific bug, because this test asserts on Qt in debug mode with NRWT, but passes with ORWT. error log with r90729: ASSERTION FAILED: enabled || !supportsProfiling() ../../../Source/WebCore/bindings/js/JSDOMWindowBase.cpp(126) : virtual bool WebCore::JSDOMWindowBase::supportsRichSourceInfo() const 486740 13 kbalazs 2011-10-19 06:50:52 -0700 (In reply to comment #12) > It isn't Chromium specific bug, because this test asserts > on Qt in debug mode with NRWT, but passes with ORWT. > > error log with r90729: > > ASSERTION FAILED: enabled || !supportsProfiling() > ../../../Source/WebCore/bindings/js/JSDOMWindowBase.cpp(126) : virtual bool WebCore::JSDOMWindowBase::supportsRichSourceInfo() const After skip, the same assert failed with /inspector/cookie-resource-match-crash on Qt-Linux-x86_32-Debug: http://build.webkit.sed.hu/results/x86-32%20Linux%20Qt%20Debug/r97849%20(19079)/inspector/cookie-resource-match-crash-log.txt 486741 14 ossy 2011-10-19 06:54:31 -0700 It is the first inspector test ... maybe skipping it too solve the problem ... 486789 15 kbalazs 2011-10-19 07:51:26 -0700 (In reply to comment #14) > It is the first inspector test ... maybe skipping it too solve the problem ... Let's try it. Skipped in http://trac.webkit.org/changeset/97862 490006 16 ossy 2011-10-25 06:45:31 -0700 One more test skipped by http://trac.webkit.org/changeset/98338 490928 17 kbalazs 2011-10-26 09:33:19 -0700 Trying a better approach to handle the bots by using test_expectations. Set the first one as CRASH+PASS: http://trac.webkit.org/changeset/98490. 1055109 18 burg 2014-12-12 14:09:04 -0800 Closing as invalid, as this bug pertains to the old inspector UI and/or its tests. Please file a new bug (https://www.webkit.org/new-inspector-bug) if the bug/feature/issue is still relevant to WebKit trunk.