Destroy window before cleaning up combobox

Currently, when we destroy a CFFL_ComboBox we'll cleanup the fontmap and then
call the destructor for the parent type. This will case the PWL_Wnd to be
destroyed. In this case, the window is a PWL_Edit. On destruction it will reset
the focus which causes the text selection to change, which asks the font map
for data but we've already destroyed the font map.

This CL forces the destruction of the window earlier in order to have the
fontmap available. A followup bug is filed to correct the location of the
fontmap so we don't have this dependency.

BUG=chromium:637546

Review-Url: https://codereview.chromium.org/2266943002

1 files changed, 8 insertions, 0 deletions

diff --git a/fpdfsdk/formfiller/cffl_formfiller.h b/fpdfsdk/formfiller/cffl_formfiller.h
index b1e323185b..060eb8f9e7 100644
--- a/fpdfsdk/formfiller/cffl_formfiller.h
+++ b/fpdfsdk/formfiller/cffl_formfiller.h
@@ -154,6 +154,14 @@ class CFFL_FormFiller : public IPWL_Provider, public CPWL_TimerHandler {
  protected:
   using CFFL_PageView2PDFWindow = std::map<CPDFSDK_PageView*, CPWL_Wnd*>;
 
+  // If the inheriting widget has its own fontmap and a PWL_Edit widget that
+  // access that fontmap then you have to call DestroyWindows before destroying
+  // the font map in order to not get a use-after-free.
+  //
+  // The font map should be stored somewhere more appropriate so it will live
+  // until the PWL_Edit is done with it. pdfium:566
+  void DestroyWindows();
+
   CPDFDoc_Environment* m_pApp;
   CPDFSDK_Widget* m_pWidget;
   CPDFSDK_Annot* m_pAnnot;