Temporarily disable NavigationHistoryTest.testNavigateBackToNoncacheableLoginPage

Temporarily disable NavigationHistoryTest.testNavigateBackToNoncacheableLoginPage

https://codereview.chromium.org/22982011 will fix chromium's form resubmission defenses. Currently, we silently re-post on back/forward navigation, which is bad. This test sets Cache-Control: no-store, which prevents the page from being in our caches. On form resubmission, we should force cache usage and only go to the network with explicit permission from the user.

BUG=263508
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=221261

[mnaganov (inactive), 2013-09-04 12:34:52]

On 2013/09/03 20:13:32, Nate Chapin wrote:

Hello, Nate!

The "no-store" policy here is used intentionally. We had a problem in Android
WebView with Google's login page (https://accounts.google.com/ServiceLoginAuth)
which uses "cache-control:no-cache, no-store". So the problem was: when one
submits invalid username / password, then navigates to the help URL, then goes
back, we were failing to display the auth page again, as it wasn't in the cache.

I can't recall now, how exactly did we fix this (and I'm in airport now, so
can't dig deeper :). Can you please ensure that this use case will not be
broken?

[Nate Chapin, 2013-09-04 16:22:42]

On 2013/09/04 12:34:52, Mikhail Naganov (Chromium) wrote:
> On 2013/09/03 20:13:32, Nate Chapin wrote:
> 
> Hello, Nate!
> 
> The "no-store" policy here is used intentionally. We had a problem in Android
> WebView with Google's login page
(https://accounts.google.com/ServiceLoginAuth)
> which uses "cache-control:no-cache, no-store". So the problem was: when one
> submits invalid username / password, then navigates to the help URL, then goes
> back, we were failing to display the auth page again, as it wasn't in the
cache.
> 
> I can't recall now, how exactly did we fix this (and I'm in airport now, so
> can't dig deeper :). Can you please ensure that this use case will not be
> broken?

I'll have to look more carefully to be sure what the proper behavior is in this
case, but I'm suspcious that not displaying the page might be the technically
correct behavior. Regardless, this is blocking a much worse bug, so I'd much
rather break it in the short term and get
https://codereview.chromium.org/22982011 landed if that's ok.

[Nate Chapin, 2013-09-04 18:06:43]

On 2013/09/04 16:22:42, Nate Chapin wrote:
> On 2013/09/04 12:34:52, Mikhail Naganov (Chromium) wrote:
> > On 2013/09/03 20:13:32, Nate Chapin wrote:
> > 
> > Hello, Nate!
> > 
> > The "no-store" policy here is used intentionally. We had a problem in
Android
> > WebView with Google's login page
> (https://accounts.google.com/ServiceLoginAuth)
> > which uses "cache-control:no-cache, no-store". So the problem was: when one
> > submits invalid username / password, then navigates to the help URL, then
goes
> > back, we were failing to display the auth page again, as it wasn't in the
> cache.
> > 
> > I can't recall now, how exactly did we fix this (and I'm in airport now, so
> > can't dig deeper :). Can you please ensure that this use case will not be
> > broken?
> 
> I'll have to look more carefully to be sure what the proper behavior is in
this
> case, but I'm suspcious that not displaying the page might be the technically
> correct behavior. Regardless, this is blocking a much worse bug, so I'd much
> rather break it in the short term and get
> https://codereview.chromium.org/22982011 landed if that's ok.

I think temporarily disabling the test makes more sense than changing the header
at this time, patch updated accordingly. I'll look at this more carefully once
the form resubmission fix is in and make sure we get the right behavior in this
case.

[darin (slow to review), 2013-09-04 18:08:41]

LGTM

[commit-bot: I haz the power, 2013-09-04 18:11:15]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/japhet@chromium.org/23464023/9001

[commit-bot: I haz the power, 2013-09-04 20:44:01]

Change committed as 221261

[joth, 2013-09-04 21:00:20]

could you open a bug to track re-enabling this test?
For reference, the test was added after this broke and was fxed via blink
rolls; see
https://b.corp.google.com/issue?id=8888772&query=8888772&gsessionid=bfFOAcn7G...

which also mentions receiving a WebViewClient.onFormResubmission() call
would be reasonable thing to expect in this flow. (But note that requires
updating client applications which is not a trivial thing to do)


Thanks


On 4 September 2013 13:44, <commit-bot@chromium.org> wrote:

> Change committed as 221261
>
>
https://chromiumcodereview.**appspot.com/23464023/<https://chromiumcodereview...
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Nate Chapin, 2013-09-04 21:08:40]

On 2013/09/04 21:00:20, joth wrote:
> could you open a bug to track re-enabling this test?
> For reference, the test was added after this broke and was fxed via blink
> rolls; see
>
https://b.corp.google.com/issue?id=8888772&query=8888772&gsessionid=bfFOAcn7G...
> 
> which also mentions receiving a WebViewClient.onFormResubmission() call
> would be reasonable thing to expect in this flow. (But note that requires
> updating client applications which is not a trivial thing to do)
> 
> 
> Thanks
> 
> 
> On 4 September 2013 13:44, <mailto:commit-bot@chromium.org> wrote:
> 
> > Change committed as 221261
> >
> >
>
https://chromiumcodereview.**appspot.com/23464023/%3Chttps://chromiumcoderevi...>
> >
> 
> To unsubscribe from this group and stop receiving emails from it, send an
email
> to mailto:chromium-reviews+unsubscribe@chromium.org.

Bug opened, thanks.