1305943 - ALT-Space is a _standard_ Windows function, no longer working in Nightly 52.0a1

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect, P2)

Description

[bugzilla]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36

Steps to reproduce:

Held down alt, pressed space, menu does not appear.
Tried on 2 Windows 10 computers 1x Windows 7 VM


Actual results:

No menu appeared, menu should be appearing.


Expected results:

Hold ALT then Space in _any other windows application ever created_ see what happens.

This is what should be happening.
I am unsure if it's my machines or Firefox, I've rebooted a few times, thinking it was me, then tested multiple computers, then tested multiple apps then tested on VMs it SEEMS to be specifically Firefox no longer recognising this command.

This needs to be put back in (if it's been removed?) as soon as humanly possible, please.

Comment 1

[bugzilla]

Keywords:

standards, hotkeys, windows, user interface, ux, ui, accessability

Comment 2

[Alice0775 White]

[Tracking Requested - why for this release]:

Comment 3

[Alice0775 White]

Control Menu no longer pops up with Alt+Space

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d0a451335c438bfda973c223f39ef1d47adc6973&tochange=949fe298aefd9e21cac89122d09d633ee438ae06

Regressed by: Bug 1300003

Comment 4

[bugzilla]

(In reply to Alice0775 White from comment #3)
> Control Menu no longer pops up with Alt+Space
> 
> Regression window:
> https://hg.mozilla.org/integration/autoland/
> pushloghtml?fromchange=d0a451335c438bfda973c223f39ef1d47adc6973&tochange=949f
> e298aefd9e21cac89122d09d633ee438ae06
> 
> Regressed by: Bug 1300003


Sorry I'm not following here, are you saying it's already been fixed?

Comment 5

[Alice0775 White]

No, not yet fixed.

Landing of Bug 1300003 caused the problem.

Comment 6

[bugzilla]

Ok sorry to hassle you, I wasn't sure if it was infact "not intended to be fixed, not a bug, design choice"  - I'm not fluent with programmer speak and what have you.

Thanks for the help, abandon thread.

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Thank you for the quick regression report!

I guess that we hit a hidden bug with bug 1300003 fix. Looks like that we have a special path for Alt+Space in HandleCharMessage():
https://dxr.mozilla.org/mozilla-central/rev/66a77b9bfe5dcacd50eccf85de7c0e7e15ce0ffd/widget/windows/KeyboardLayout.cpp#2492-2499

But new code consumes Alt+Space's WM_SYSCHAR message. That's the regression cause.

I'll fix this later because I want to land more risky patches as soon as possible for reducing the risk. Then, I'll be back here.

Comment 8

[bugzilla]

New nightly just rolled out, still same behaviour (but perhaps it wasn't rolled into this released)

Comment 9

[Liviu Cirdei]

This issue is not yet fixed. You can check the fix after the status of this bug report will be Resolved Fixed.

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=d2bd5d738e66

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 1305943 Don't consume following WM_SYSCHAR message for some key combinations which are reserved by the system

When key combination is reserved by the system, web apps shouldn't be able to consume the key events.  In such case, we've decided that we never expose the key events in web contents (including chrome contents).  Therefore, NativeKey stops dispatching keyboard events only for Alt+Space.

However, new code of the fix of bug 1300003 always consumes WM_SYSCHAR which follows WM_SYSKEYDOWN of Alt+Space.  This is the cause of bug 1305943.

For fixing this bug, NativeKey should have a helper method, IsReservedBySystem(), and when it returns true, it should do nothing when Handle*Message() is called and should not consume following WM_SYSCHAR messages at handling WM_*KEYDOWN.

Unfortunately, it's impossible to test this regression because nsDOMWindowUtils::SendNativeKeyEvent() may call nsIWidget::SynthesizeNativeKeyEvent() asynchronously.  See <https://dxr.mozilla.org/mozilla-central/source/dom/base/nsDOMWindowUtils.cpp#1105-1108>.  Therefore, it cannot return if it's consumed.

Review commit: https://reviewboard.mozilla.org/r/82632/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/82632/

Comment 12

[Marcia Knous [:marcia]]

Tracking 52+ for this regression.

Comment 13

[Makoto Kato [:m_kato]]

Comment on attachment 8797007 [details]
Bug 1305943 Don't consume following WM_SYSCHAR message for some key combinations which are reserved by the system

https://reviewboard.mozilla.org/r/82632/#review81654

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b3947e0eeeb8
Don't consume following WM_SYSCHAR message for some key combinations which are reserved by the system r=m_kato

Comment 15

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/b3947e0eeeb8

Comment 16

[bugzilla]

Thanks for fixing this and sorry for my ... ranty subject for the bug.   I thought this might have been a deliberate, obstinate 'we know best' change to the software.   Ignoring standards bugs the **** out of me (see: Chrome titlebar iconsize under Windows 7 classic UI mode - only app I know of that disobeys Windows standards)

Glad it'll be fixed, I use Windows keyboard hotkeys literally hundreds of times each day.
Thanks again