Context menu operations like Cut/Copy/Paste etc would not work in pages rendered by ChromeFrame. The context menu is displayed

by the ChromeFrame plugin which grabs focus to ensure that the menu has focus, and then restores focus back once we select an
item. The latter step sends over a notification to Chrome via an automation message which then informs the view. This resets the
webview item selection which results in this bug.

Fix is to send over an additional flag to Chrome in the SetInitialFocus which indicates whether we need to inform the view about
the focus change or not.

Fixes bug http://code.google.com/p/chromium/issues/detail?id=41523

Bug=41523

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

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

1 files changed, 3 insertions, 2 deletions

diff --git a/chrome/browser/external_tab_container.cc b/chrome/browser/external_tab_container.cc
index 4c46493..42db662 100644
--- a/chrome/browser/external_tab_container.cc
+++ b/chrome/browser/external_tab_container.cc
@@ -237,7 +237,8 @@ void ExternalTabContainer::ProcessUnhandledAccelerator(const MSG& msg) {
                                                         GetFocusManager());
 }
 
-void ExternalTabContainer::FocusThroughTabTraversal(bool reverse) {
+void ExternalTabContainer::FocusThroughTabTraversal(
+    bool reverse, bool restore_focus_to_view) {
   DCHECK(tab_contents_);
   if (tab_contents_)
     tab_contents_->Focus();
@@ -246,7 +247,7 @@ void ExternalTabContainer::FocusThroughTabTraversal(bool reverse) {
   // TabContentsViewWin::Focus() above. This method eventually calls SetFocus
   // on the native window, which could end up dispatching messages like
   // WM_DESTROY for the external tab.
-  if (tab_contents_)
+  if (tab_contents_ && restore_focus_to_view)
     tab_contents_->FocusThroughTabTraversal(reverse);
 }