[Webkit-unassigned] [Bug 168186] [GTK] Handle caps lock indicator in event modifiers

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=168186

Michael Catanzaro <mcatanzaro at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #301299|review?                     |review+
              Flags|                            |

--- Comment #3 from Michael Catanzaro <mcatanzaro at igalia.com> ---
Comment on attachment 301299
  --> https://bugs.webkit.org/attachment.cgi?id=301299
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=301299&action=review

> LayoutTests/ChangeLog:9
> +        Add platform specific results for fast/events/special-key-events-in-input-text.html. This patch fixes the caps
> +        lock key case, but we still have different results in the PrintScreen case.

What's different about the PrintScreen case? Do we not ever want to fix it?

> Source/WebCore/platform/PlatformKeyboardEvent.h:169
> +        static bool modifiersContainCapsLock(unsigned);

This header is already a mess, so I guess it's OK, but I dislike adding a special function here just for CapsLock. I'd prefer a generic function:

static bool modifiersContainModifier(unsigned, PlatformEvent::Modifier)

that you would pass PlatformEvent::Modifier::CapsLockKey to. Even if it's currently only used for CapsLock. But your choice.

> Source/WebCore/platform/gtk/PlatformKeyboardEventGtk.cpp:1325
> +    // In X11 GDK_LOCK_MASK could be CapsLock or ShiftLock. What GTK+ does in the X11 backend is checking if

This code really confused me. I wrote a decent-length WTF comment to ask you to explain why it would ever be impossible for GTK+ to generate GDK_KEY_Caps_Lock. The key is to understand that it depends on the nutty modifier mapping of the X server. So I'd add that to your comment:

"In X11 GDK_LOCK_MASK could be CapsLock or ShiftLock, depending on the modifier mapping of the X server."

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170212/489a94dd/attachment-0001.html>