Lync ContactList WPF control hotkey/shortcut key stealing key presses from WebBrowser

Question

The Problem

Lync has some hotkeys/shortcut keys for changing the tabs in the ContactList control. These hotkeys are 'g', 's' and 'r'. When I press any of these keys whilst having a HTML input control focused inside a WebBrowser on any web page, the key presses are going to the ContactList control instead of the WebBrowser control. The key presses aren't stolen when typing into a control outside the browser, such as a WPF TextBox control.

Steps to reproduce the problem

1. Have Microsoft Lync 2013 installed
2. Download and install the Microsoft Lync 2013 client sdk from http://www.microsoft.com/en-au/download/details.aspx?id=36824
3. Create a .net 4.0 wpf application. Drag and drop a ContactList control into MainWindow so it automatically sets up the references and namespaces

4. Paste the following code inside the Window element in MainWindow.xaml

   <Window...
   <Grid>
       <Grid.ColumnDefinitions>
           <ColumnDefinition Width="auto" />
           <ColumnDefinition Width="*" />
       </Grid.ColumnDefinitions>
       <controls:ContactList Name="contactList1" Grid.Column="0" />
       <WebBrowser Grid.Column="1" Source="http://www.google.com"  />
   </Grid>
   

5. Press the 'r', 'g' or 's' key into the google search box and notice how the key presses go to the lync control instead of the search box. Any other keys work like normal.

Things I've tried

I've tried to stop the key event bubbling to the ContactList control. However i haven't had much success with this.

disable event-bubbling c# wpf

WPF prevent event bubbling outside of a control

Answer 1

Found the answer here: AccessKey Pressed Event Raised when pressing access key without ALT

This behaviour occurs because WPF doesn't require alt to be held down in order for AccessKeys to work. Where as WinForms does. In this case pressing 'g', 's', or 'r' from within the WebBrowser focuses the ClientControl, but I only want this to happen when holding down alt. I don't know why this problem only seems to happen with WebBrowser though.

From the msdn link:

We have defined an access key on a label, which gives focus to a textbox.

We have a second readonly textbox on the same user control.

When clicking inside the readonly textbox and pressing the access key without ALT (e.g. L instead of ALT + L) the focus change is done anyway.

Is it possible to disable this behaviour, i.e. is it possible to ensure, that the access key is only working when pressed together with ALT?

The following xaml shows the issue:

<Window x:Class="Window1"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
SizeToContent="Height"
Width="300" WindowStartupLocation="CenterScreen">
    <StackPanel Orientation="Vertical">
        <TextBox IsReadOnly="True" Text="ReadOnly - give focus and press l" />
        <Label Content="_Label:"  Target="{Binding ElementName=box}"/>
        <TextBox x:Name="box" />
    </StackPanel>
</Window>

The solution

Menu and ToolBar menmonics work without pressing Alt key. We decided that we will have uniform behavior in all cases so access key work withour pressing Alt key.

I understand that this is not in parity with Forms and we will consider this issue and change the behavior in the next version.

For now as a workaround you can redister a class handler for all AccessKeyPressed events and handle the event if Alt key is not pressed.

EventManager.RegisterClassHandler(typeof(UIElement), AccessKeyManager.AccessKeyPressedEvent, new AccessKeyPressedEventHandler(OnAccessKeyPressed));

private void OnAccessKeyPressed(object sender, AccessKeyPressedEventArgs e)
{
    if (!e.Handled && e.Scope == null && (e.Target == null || e.Target == label))
    {
        // If Alt key is not pressed - handle the event
        if ((Keyboard.Modifiers & ModifierKeys.Alt) != ModifierKeys.Alt)
        {
            e.Target = null;
            e.Handled = true;
        }
    }
}

I added the solution code to the MainWindow class and everything works as expected.