Cleanup: Slight simplification in the PDFiumEngine dtor.

pdf/pdfium/pdfium_engine.cc

Index: pdf/pdfium/pdfium_engine.cc
diff --git a/pdf/pdfium/pdfium_engine.cc b/pdf/pdfium/pdfium_engine.cc
index e580fede6aba69640b283f2395d9c2b5252c2021..fc0bc9b3aa7a6e683ad568c338c951365f4aee5a 100644
--- a/pdf/pdfium/pdfium_engine.cc
+++ b/pdf/pdfium/pdfium_engine.cc
@@ -661,17 +661,11 @@ PDFiumEngine::~PDFiumEngine() {
     pages_[i]->Unload();
 
   if (doc_) {
-    if (form_) {
-      FORM_DoDocumentAAction(form_, FPDFDOC_AACTION_WC);
-    }
+    FORM_DoDocumentAAction(form_, FPDFDOC_AACTION_WC);
     FPDF_CloseDocument(doc_);
-    if (form_) {
-      FPDFDOC_ExitFormFillEnvironment(form_);
-    }
+    FPDFDOC_ExitFormFillEnvironment(form_);

[Tom Sepez, 2015/05/15 15:06:31]

Curious about the ordering here, in that the same block in embedder_test.cpp
does the ExitFormFillEnvironment before the CloseDocument.  My intuition would
tell me that the FF env's lifetime should be nested within the document's
lifetime, but I've not actually looked.

[Lei Zhang, 2015/05/15 21:23:09]

It used to be the other way around, but changed here. See the discussion with
Bo:
https://codereview.chromium.org/705823002/diff/60001/pdf/pdfium/pdfium_engine...

Calling FPDFDOC_InitFormFillEnvironment(doc_) does end up creating pointers that
point to |doc_|, but as long as we call FPDFDOC_ExitFormFillEnvironment()
immediately after FPDF_CloseDocument(), there's no opportunity to accidentally
use |doc_|. At least that's how it looks on the master branch.

   }
-
-  if (fpdf_availability_)
-    FPDFAvail_Destroy(fpdf_availability_);
+  FPDFAvail_Destroy(fpdf_availability_);
 
   STLDeleteElements(&pages_);
 }