790486 - Work - Alt + any other key is not detected from WinRT widget code

Status: RESOLVED FIXED

(Firefox for Metro Graveyard :: General, defect)

Description

[Brian R. Bondy [:bbondy]]

Currently we aren't picking up any WinRT keypress combinations when alt is held down.  This bug is to add platform support for key presses when alt is down.

Some keyboard shortcuts that will need this is alt+left and alt+right which should go back and forward in history.

Comment 1

[Brian R. Bondy [:bbondy]]

I think the best route for this is as discussed at the meeting:
Provide alternate shortcuts not involving the alt key.

I'd like Jim to verify my claim that we can't easily add support for this with our WinRT browser first in case I missed something.

Comment 2

[Jim Mathies [:jimm]]

ping

Comment 3

[Brian R. Bondy [:bbondy]]

We aren't going to fight the platform for this one and instead provide alternate shortcut keys.

Comment 4

[Brian R. Bondy [:bbondy]]

I noticed that IE10 Metro can use Alt + left and Alt+right to go forward and back so I think we need to look at this again.

Comment 5

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

Brian and I investigated handling "Alt" key presses at the Metro team meet-up this week.  A patch is on the way.

Comment 6

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

Attachment: Patch v1

This patch fixes the issue on my machine with no obvious side effects.  It changes MetroInput to handle the AcceleratorKeyActivated event instead of the KeyUp, KeyDown, and CharacterReceived events.  AcceleratorKeyActivated is fired when any key is pressed, including alt (which is treated as a special "system key").

Comment 7

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

I should mention also that the patch hooks up alt+left and alt+right keyboard shortcuts but does not hook up any other keyboard shortcuts.  I was thinking the other shortcuts could be hooked up in bug 785473, but I'd be willing to update this patch to hook up other alt keyboard shortcuts

Comment 8

[Brian R. Bondy [:bbondy]]

Comment on attachment 703742 [details] [diff] [review]
Patch v1

Review of attachment 703742 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good!

::: widget/windows/winrt/FrameworkView.h
@@ +182,5 @@
>    // rendering from that for print/preview in the different thread.
>    //Microsoft::WRL::ComPtr<IWICImagingFactory2> mWicFactory;
>    Microsoft::WRL::ComPtr<MetroApp> mMetroApp;
>    Microsoft::WRL::ComPtr<ABI::Windows::UI::Core::ICoreWindow> mWindow;
> +  Microsoft::WRL::ComPtr<ABI::Windows::UI::Core::ICoreDispatcher> mDispatcher;

nit: I think you can just do Microsoft::WRL::ComPtr<ICoreDispatcher> mDispatcher; here

::: widget/windows/winrt/MetroInput.cpp
@@ +219,5 @@
> +  LogFunction();
> +  Log(L"Accelerator key type: %d\n"
> +      L"Accelerator key value: %d",
> +       type,
> +       vkey);

nit: Collapse this all to one line if you can with space.

@@ +1385,5 @@
> +  coreAcceleratorKeys->add_AcceleratorKeyActivated(
> +      WRL::Callback<AcceleratorKeyActivatedHandler>(
> +                                  this,
> +                                  &MetroInput::OnAcceleratorKeyActivated).Get(),
> +      &mTokenAcceleratorKeyActivated);

nit: whitespace

Comment 9

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

Landed on elm (with nits fixed):
  https://hg.mozilla.org/projects/elm/rev/9e271ea22c71

First elm build containing the patch:
  https://tbpl.mozilla.org/?tree=Elm&rev=9e271ea22c71

Comment 10

[Matt Brubeck (:mbrubeck)]

Resolving bugs in the Firefox for Metro product that are fixed on the elm branch.  Sorry for the bugspam.  Search your email for "bugspam-elm" if you want to find and delete all of these messages at once.