Our InPlaceMenu implementation is only partially being used.

We had a leftover call to InPlaceMenuDestroy without creating a menu in the first place.
This caused us to delete IE's menu and fail the first check inside ieframe!CDocObjectHost::OnInitMenuPopup.
It took a while to figure this out and even longer to figure out why our menu was NULL in this case and not mshtml's.

I don't think that there are any bad side effects with this change but I ask the reviewer to check.

The visible change is that the Print menu item will become enabled and visible whereas Page Setup will be disabled and Print Preview will (correctly atm) not be visible for GCF documents.

BUG=24034, 47074
TEST=See description above and bug report.

Review URL: http://codereview.chromium.org/3034033

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@53786 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 5 insertions, 1 deletions

diff --git a/chrome_frame/ole_document_impl.h b/chrome_frame/ole_document_impl.h
index 4c346d8..9ce1bbe 100644
--- a/chrome_frame/ole_document_impl.h
+++ b/chrome_frame/ole_document_impl.h
@@ -209,7 +209,11 @@ class ATL_NO_VTABLE IOleDocumentViewImpl : public IOleDocumentView {
         hr = t->ActiveXDocActivate(OLEIVERB_UIACTIVATE);
       }
     } else {
-      t->InPlaceMenuDestroy();
+      // Menu integration is still not complete, so do not destroy
+      // IE's menus.  If we call InPlaceMenuDestroy here, menu items such
+      // as Print etc will be disabled and we will not get calls to QueryStatus
+      // for those commands.
+      // t->InPlaceMenuDestroy();
       // t->DestroyToolbar();
       hr = t->UIDeactivate();
     }