dev-tools does nothing on back button to a posted page when disable-cache is enabled |
|||||||
Issue descriptionAfter https://codereview.chromium.org/2266913002, dev-tools blocks WebCachePolicy::ReturnCacheDataDontLoad requests if the cache is disabled. Previously, disable-cache mapped all requests to BypassingCache. Chrome applies ReturnCacheDataDontLoad to back/fwd POST navigations. This is to prevent the same POST from occurring twice on the server. Before the above patch landed, the POST would in fact happen twice if disable-cache was checked. That's not good. After the patch landed, that no longer happens. However, if you navigate back to a POSTed page, nothing happens because the navigation is cancelled since the main resource is blocked. What's the correct UX here? Or is it WAI? Reproduction: 1) open a dev tools window and turn on disable-cache 2) navigate to https://cr.kungfoo.net/jkarlin/post/ 3) post something 4) note the timestamp in the resulting page 5) navigate somewhere else, e.g., http://example.com 6) hit the back button In the past (e.g., M54), the back button would have caused a resend of the POST request. In ToT nothing at all happens when you hit the back button. You can still hold down the back button to navigation through history.
,
Nov 15 2016
,
Nov 15 2016
To fix this we need to return the proper error code, net::ERR_CACHE_MISS. Then we'll get the usual "Confirm Form Resubmission" screen.
,
Nov 15 2016
CL https://codereview.chromium.org/2508473002/ is up to fix this.
,
Nov 16 2016
,
Nov 17 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c1331a41ffd5d4dce093398c03619eb8cc06f323 commit c1331a41ffd5d4dce093398c03619eb8cc06f323 Author: jkarlin <jkarlin@chromium.org> Date: Thu Nov 17 20:18:54 2016 [DevTools] Properly handle cache-only requests when cache is disabled If a request is cache-only (e.g., back navigation to a POST) but "disable cache" is checked in dev-tools, then set the cache policy to both load only from cache and bypass the cache. This will result in the proper ERR_CACHE_MISS from the network stack. BUG= 663728 Review-Url: https://codereview.chromium.org/2508473002 Cr-Commit-Position: refs/heads/master@{#432946} [modify] https://crrev.com/c1331a41ffd5d4dce093398c03619eb8cc06f323/content/child/web_url_request_util.cc [modify] https://crrev.com/c1331a41ffd5d4dce093398c03619eb8cc06f323/net/http/http_cache_transaction.cc [modify] https://crrev.com/c1331a41ffd5d4dce093398c03619eb8cc06f323/net/http/http_cache_unittest.cc [modify] https://crrev.com/c1331a41ffd5d4dce093398c03619eb8cc06f323/third_party/WebKit/Source/core/inspector/InspectorNetworkAgent.cpp [modify] https://crrev.com/c1331a41ffd5d4dce093398c03619eb8cc06f323/third_party/WebKit/public/platform/WebCachePolicy.h
,
Nov 18 2016
So far so good on canary. Would like to merge on Monday if things still look good then.
,
Nov 18 2016
Your change meets the bar and is auto-approved for M55 (branch: 2883)
,
Nov 21 2016
The bot hasn't updated so I'll do it manually. Landed https://codereview.chromium.org/2517983002/
,
Nov 29 2016
Tested this issue on Windows 10, Ubuntu 14.04 and Mac 10.11.6 with chrome version #55.0.2883.70 These are the steps i followed 1. Opened the google chrome 2. Open dev tools and then network tab and check the disable cache checkbox. 3. Navigated to "https://cr.kungfoo.net/jkarlin/post/" and clicked on send button 4. And then navigated to "https://wikipedia.com" 5. clicked on the back button and observed "Confirm form resubmission" error page 6. On reloading that page we are navigated to "https://cr.kungfoo.net/jkarlin/post/posted.php" and there is new server time. Note: -------- In Windows 10 with chrome stable version M54-54.0.2840.99 we didn't observe the step 5. Is this "Confirm form re-submission" error page is expected in M55-55.0.2883.70 Please look into the attached screen-cast for your reference
,
Nov 29 2016
Right, M54 was broken when disable-cache was on. It went ahead and sent the request when it should have confirmed first. The M55 behavior is correct.
,
Nov 29 2016
As Per Comment #11, adding TE verified labels |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by kozyatinskiy@chromium.org
, Nov 14 2016Status: Assigned (was: Untriaged)