Fix progressive loading of PDFs with network service.

The problem was different timing of loading messages. Normally, DocumentLoaderImpl::DidRead is called very early which calls into DocumentLoaderImpl::SaveBuffer. The latter sees that the request was in |pending_requests_| and then calls OnPendingRequestComplete which loads the information about the document (e.g. number of pages, linearized PDF info). With the network service,
OutOfProcessInstance::DidChangeView was being called before the DidRead calls which was causing |pending_requests_| to be reset.

The fix is to only reset pending_requests_ in PDFiumEngine::CalculateVisiblePages if we have already loaded the PDF document structure. This was the intended effect of that code; the extra check wasn't needed before the network service because we were always reaching that function after the document info was loaded.

Bug: 705114

Change-Id: I4e668ebfdda0c17ede3c6daa951dea0a1b38eb05
Reviewed-on: https://chromium-review.googlesource.com/1147932Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/master@{#577637}

pdf/pdfium/pdfium_engine.cc

@@ -2714,7 +2714,13 @@ void PDFiumEngine::LoadForm() {
 }
 
 void PDFiumEngine::CalculateVisiblePages() {
-  if (!doc_loader_)
+  // Early return if the PDF isn't being loaded or if we don't have the document
+  // info yet. The latter is important because otherwise as the PDF is being
+  // initialized by the renderer there could be races that call this method
+  // before we get the initial network responses. The document loader depends on
+  // the list of pending requests to be valid for progressive loading to
+  // function.
+  if (!doc_loader_ || pages_.empty())
     return;
   // Clear pending requests queue, since it may contain requests to the pages
   // that are already invisible (after scrolling for example).