Excel CustomTaskPane with WebBrowser control - keyboard/focus issues

Ok I was able to fix the issue using the following code

protected override void WndProc(ref Message m)
{
  const int WM_PARENTNOTIFY = 528;
  if(m.Msg == WM_PARENTNOTIFY && !this.Focused)
  {
    this.Focus();
  }
  base.WndProc(ref m);
}

I added this function to my TaskPaneView which is simply a UserControl with that webbrowser child. I don't have a deep understanding of why or how this works, but basically I think what's happening is i'm intercepting WndProc which is some low-level function that process messages sent to the window. I use it to check to see if the message is 528, which I think means notifyParent. I don't know if this is exactly which message I should be listening for, but it seems to work.

Once I have the right message message I check to see if the TaskPaneView has focus and if not, I give it focus with the focus() function. I did testing earlier that showed if I manually invoked focus on the TaskPaneView everything worked fine. So if I don't have focus, then manually request focus and we are all good.

I would appreciate it if someone can provide a more detailed explaination as to why this works so I can understand it better, but at least I solved the problem. Thanks Jeremy Thompson for getting me thinking about this issue in a new way.

Q: Provide a more detailed explanation as to why this works so I can understand it better

Glad you got it working! To perform a root cause analysis we'd need to see where that 528 message gets sent and we'd need the Microsoft Excel source code to do that.

I don't think its worth spending anymore time troubleshooting it or working out why it happens because IT IS A BUG! Logging a Connect bug to help Microsoft fix it is the best thing you can do. We can only work around it, it's a problem in their source code.

It is quite rare you find these scenario's in VSTO to see bugs and you've certainly found one; where a user enters text input into an Add-Ins textbox and the message flows into a cell in the worksheet!! In my situation; where the message wasn't pumped to the Calendars_SelectedChange() event. So we can see a bit of a theme of the behavior forming here that Hans explains well (Quoting from the Q&A I linked to in my comment):

What's never not a problem (ie can often be problematic) is that you rely on the message pump in Excel to dispatch Windows messages, the messages that make these controls respond to input. This goes wrong in WPF as much as Winforms, they have their own dispatch loop that filters messages before they are delivered to the window. Key things that go wrong when their respective dispatcher isn't used are stuff like tabbing and short-cut keystrokes.

And then some, this kind of problem would be induced by Excel doing its own filtering before dispatching messages. I'd guess at an anti-malware feature, Microsoft is forever worried about programs messing with Office apps.

And dont forget the VSTO WPF Connect case with menu's not receiving click events. The workaround involved using the DispatcherFrame to pump messages and subscribe to GotFocusEvent and LostFocusEvent for the menu.

So the bug is to do with controls that respond to input and the void WndProc(ref Message m) messages being incorrectly filtered or redirected in the dispatch loop.