[abort] [do not commit] don't stop loaders on canceled navigations

[do not commit] don't stop loaders on canceled navigations

BUG=308257

[mkosiba (inactive), 2014-01-09 18:17:18]

Hi Darin!
  Just wanted to get some early feedback on whether you consider this the
correct approach to fixing the "if you perform a navigation which is immediately
cancelled by a ResourceThrottle XHRs get cancelled" problem.
  A full review is not necessary since I still need to figure out why this
change is breaking WebContentsImplBrowserTest.DidStopLoadingDetailsWithPending
  The Chromium-side of this CL is https://codereview.chromium.org/132143003/

[Nate Chapin, 2014-01-09 21:04:32]

On 2014/01/09 18:17:18, mkosiba wrote:
> Hi Darin!
>   Just wanted to get some early feedback on whether you consider this the
> correct approach to fixing the "if you perform a navigation which is
immediately
> cancelled by a ResourceThrottle XHRs get cancelled" problem.
>   A full review is not necessary since I still need to figure out why this
> change is breaking WebContentsImplBrowserTest.DidStopLoadingDetailsWithPending
>   The Chromium-side of this CL is https://codereview.chromium.org/132143003/

I wonder if we can do this without the didRequestStartForFrame callback. Due to
some recent refactorings, we should be fairly resilient to having resources
associated with both the provisional and the committed DocumentLoader in flight
at the same time.

[mkosiba (inactive), 2014-01-13 15:20:13]

On 2014/01/09 21:04:32, Nate Chapin wrote:
> On 2014/01/09 18:17:18, mkosiba wrote:
> > Hi Darin!
> >   Just wanted to get some early feedback on whether you consider this the
> > correct approach to fixing the "if you perform a navigation which is
> immediately
> > cancelled by a ResourceThrottle XHRs get cancelled" problem.
> >   A full review is not necessary since I still need to figure out why this
> > change is breaking
WebContentsImplBrowserTest.DidStopLoadingDetailsWithPending
> >   The Chromium-side of this CL is https://codereview.chromium.org/132143003/
> 
> I wonder if we can do this without the didRequestStartForFrame callback. Due
to
> some recent refactorings, we should be fairly resilient to having resources
> associated with both the provisional and the committed DocumentLoader in
flight
> at the same time.

I was a bit concerned that having both run at the same time means that they're
competing for bandwidth which was the main motivation for the
didRequestStartForFrame
callback. If you don't think this will be an issue I can try dropping it.