[UI Events] Support "Super" and "Hyper" modifier state on Linux

RESOLVED WONTFIX

Status

()

defect
RESOLVED WONTFIX
5 years ago
8 months ago

People

(Reporter: masayuki, Assigned: masayuki)

Tracking

(Blocks 2 bugs)

Trunk
All
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

()

Attachments

(5 attachments, 3 obsolete attachments)

10.76 KB, patch
Details | Diff | Splinter Review
112.20 KB, patch
Details | Diff | Splinter Review
1.20 KB, patch
Details | Diff | Splinter Review
1.20 KB, patch
Details | Diff | Splinter Review
12.36 KB, patch
Details | Diff | Splinter Review
D3E now defines "Super" and "Hyper" modifiers. That means that with typical mapping on Linux, Pressing Windows logo key shouldn't cause .getModifierState("OS") returning true.

However, we should new modifier state with XUL <key> element, like we did in bug 751749.

There are two options about this:
1. Adding "super" and "hyper" support to XUL <key> element strictly.
2. Mapping "os" of XUL <key> element to "super" and "hyper" too.

I like the approach #2. How about you, Enn?
Flags: needinfo?(enndeakin)

Comment 1

5 years ago
> That means that with typical mapping on Linux, Pressing Windows logo key shouldn't
> cause .getModifierState("OS") returning true.

Why not? Won't there be some compatibility issue here?
Flags: needinfo?(enndeakin)
(In reply to Neil Deakin from comment #1)
> > That means that with typical mapping on Linux, Pressing Windows logo key shouldn't
> > cause .getModifierState("OS") returning true.
> 
> Why not? Won't there be some compatibility issue here?

For web contents, .getModifierState() is an experimental feature. So, we don't need to worry about the backward compatibility.

For addon developers, "os" value of modifiers attribute of <key> event isn't so. We should keep backward compatibility if it's possible. We defined the "os" value in MDN like:

> os: Windows logo key on Windows, Super or Hyper key on Linux. This shouldn't be specified
> directly because it may conflict with system wide shortcut key. Requires Gecko 17.0

Comment 3

5 years ago
OK, seems fine.
I'd recommend making both getModifierState("OS") and getModifierState("Super") return true if the Super key is pressed.  Probably similarly for Hyper.
(In reply to Karl Tomlinson (needinfo?:karlt) from comment #4)
> I'd recommend making both getModifierState("OS") and
> getModifierState("Super") return true if the Super key is pressed.  Probably
> similarly for Hyper.

Although, I don't think so because "OS" state should be activated by "OS" key. However, I should take your concern to WG before fixing this bug. Is this your concern compatibility with Windows?
Yes, the keys are the same whatever the operating system, and I'm concerned that giving them different names will mean that things will work on one operating system but not another.
See Also: → 936319
This bug should be fixed by 4 patches. The 4th patch's spec is still unstable because I'm waiting a reply from D3E WG members.

The first, second and third patches must be stable.
Attachment #8448558 - Attachment is obsolete: true
This patch makes "Super", "Hyper" and "OS" modifier states shared. I.e., one of them is active, all of them becomes true.
I think that this is the best approach for web apps. This patch adds a virtual modifier, "SystemAccel", which is active if a modifier state which is used for system wide shortcut keys is active.

Web apps can ignore all key/mouse events like:

function eventHandler(event)
{
  if (event.getModifierState("SystemAccel")) {
    return;
  }
  // Do something
}
Summary: Support "Super" and "Hyper" modifier state on Linux → [UI Events] Support "Super" and "Hyper" modifier state on Linux
Chromium is now completely not using "Super" and "Hyper" as KeyboardEvent.key value nor modifier state. So, we should stop using them.
Status: ASSIGNED → RESOLVED
Closed: 8 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.