Re: Resubmission warning for Android

358 views
Skip to first unread message

Sriram Mouli

unread,
Feb 17, 2014, 8:17:16 AM2/17/14
to Przemysław Pietrzkiewicz, Chromium-dev
Hi P,

Thanks for the quick response. Sorry for not being clear. You are right that the ERR_CACHE_MISS will be returned in certain cases, but then if there is a cache miss, then I think a network request has to be fired to get the response again.In this case, the request stops at cache miss and the error is returned to the ContentViewCore::didFailLoad().

Just to give a clear picture of code flow,
1. I launch the login page of a URL, www.asana.com
2. Enter a invalid credentials and attempt to sign in. Sign in fails and I am on the same page with an error.
3. I try to reload the page using ContentViewCore::reload().
4. Handle the repost warning message and call ContentViewCore::continuePendingReload().

But after this I immediately get a error -400. 


On Mon, Feb 17, 2014 at 5:25 PM, Przemysław Pietrzkiewicz <p...@chromium.org> wrote:
Hello, Sriram!

As far as I understand, the ERR_CACHE_MISS is not caused by a bug - this is a legitimate behavior independent from the resubmission dialog. Let me explain.

When Chrome loads a page, there are a few types of load:
- regular load - happens when the user enters url and hits enter or clicks on a link
- reload - happens when the user hits the "reload" button
- history load (or tab restore) - happens when the browser is started after being killed and restores its tab, or when the user hits the "back" button

Now, form resubmission warning is supposed to be displayed when POST data are to be sent again in the "reload" type of load.

ERR_CACHE_MISS is supposed to be returned from the cache layer when POST data are to be sent again in the "history load" type of load.

So, these are supposed to be disjoint - I suppose you might be somehow triggering the wrong codepath to perform the load, but that's only a guess.

I hope this helps - if you have further questions, please reply to me *and* chromi...@chromium.org , so that other people can help as well (my understanding of load policies is quite shallow).

Cheers and good luck!
P.


On Mon, Feb 17, 2014 at 12:16 PM, Sriram Mouli <srim...@gmail.com> wrote:
Hi,

Apologies for contacting you directly. However I am stuck in a problem and wanted to see if you can give me some pointers related to this.
Since I saw that you have worked in an area related to that, hence e-mail'ing you directly.
This is with connection to the form resubmission warning. I am working on a old trunk which dates back to Sept11, 2013 (222409) . I see that you have made the changes related to this on Oct23, 2013(230226) .
When I am trying to implement a similar change for form repost warning in my checked out version, I am getting a ERR_CACHE_MISS and the post request is never submitted again even after clicking on Confirm resubmission.
Now my problem is I cannot merge the latest changes at this point, so I wanted to check if you would by any chance know if an issue related to for resubmission was fixed during this time and only after that you added the dialog?


--
Rgds
Sriram




--
Rgds
Sriram

Przemysław Pietrzkiewicz

unread,
Feb 18, 2014, 5:17:26 AM2/18/14
to Sriram Mouli, Chromium-dev
Interesting - thank you for clarification.

Can you rebase and apply these changes https://codereview.chromium.org/27461003 to your old checkout and see if the problem reproduces (or is this exactly what you did?)?

Did you make any other modifications in your checkout, or is it clean trunk at 222409 + added resubmission warning?

Cheers,
P.

Sriram Mouli

unread,
Feb 18, 2014, 11:48:18 AM2/18/14
to chromi...@chromium.org, Sriram Mouli, p...@chromium.org, Chromium-dev


Thank you for following it up. Actually I figured the change that  fixed this issue/behavior,just running some tests.
There has been a subtle change to the cache policy in ResourceFetcher.cpp - earlier located at src/third_party/WebKit/Source/core/loader/cache/ResourceFetcher.cpp and now moved to src/third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp.
The change is in "ResourceFetcher::resourceRequestCachePolicy(..)" where the type of cache policy was being sent to "ReturnCacheDataDontLoad" in the code base that we were using.
Changing to use "ReloadIgnoringCacheData" like the current version does, fixes the issue and the page is re-loaded as expected.
Reply all
Reply to author
Forward
0 new messages