Probably related to issue 649875

I was able to reproduce the issue. It seems like after the user uses "save page as" to save the page, the URL_Requests are set with FILTER_TYPE_GZIP and the delegate info was ResourceScheduler. My guess would be if that happens, the response won't be used to load the webpage. 

This is SaveAs issue on WIndows, changing component.

Pending requests are explicitly cancelled prior to starting a Save As operation. lukasza: Do you know if that requirement can be relaxed?

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

lukasza@ just checking in on #4.  Thanks!

Thanks for the ping.

I don't know what is referred to in #c4 by "requests are explicitly cancelled".  I see a call to WebContentsImpl::Stop from WebContentsImpl::*SavePage methods, but I thought that this would only stop navigations, not XHRs.

Anyway, I think it should be fine to not stop the pending requests (both for navigations and XHRs).  I don't really understand the benefit of stopping the navigations or other pending requests.  Even if we don't stop the navigations, the page might change while save is in progress (we don't stop javascript from executing).

FWIW, this code traces back to the initial commit:

552	void WebContents::SavePage(const std::wstring& main_file,
553	                           const std::wstring& dir_path,
554	                           SavePackage::SavePackageType save_type) {
555	  // Stop the page from navigating.
556	  Stop();

I agree to lukasza that it does not make sense to stop the requests. So I think the Stop() call can be removed.