680832 - Implement DOM3 KeyboardEvent.locale and CompositionEvent.locale

Status: RESOLVED INVALID

(Core :: DOM: Events, enhancement)

Description

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

I guess the locale information is needed for some special keys.

E.g., VK_KANA and VK_HANGUL have same keycode on Windows, but we should use preferred key names for each language.

Comment 1

[Aharon (Vladimir) Lanin]

This feature would be useful in online editors, for things like choosing language-specific quote marks, language-specific digits, and inline directionality changes.

It is implemented in IE9.

Attaching a test case.

Comment 2

[Aharon (Vladimir) Lanin]

Attachment: test case

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

This is useful yes. Need to be just very careful with privacy and exposing this data only during
trusted event dispatch.

Comment 4

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

I don't find a way to get current keyboard/IME locale on GTK. Karlt, do you know whether it's possible or not?

Comment 5

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

Attachment: testcase

Comment 6

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

Attachment: testcase

Comment 7

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

Attachment: part.1 Implement KeyboardEvent.locale and CompositionEvent.locale

Comment 8

[Karl Tomlinson (:karlt)]

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) (almost offline 5/1-5/6) from comment #4)
> I don't find a way to get current keyboard/IME locale on GTK. Karlt, do you
> know whether it's possible or not?

It looks like the closest thing for a keyboard layout is XkbNamesRec::groups which can be filled in using  XkbGetNames() with XkbGroupNamesMask.
http://www.x.org/releases/current/doc/libX11/XKB/xkblib.html#The_XkbNamesRec_Structure

I expect that would return groups names like "English (US)", "English (Dvorak)", "Belgian", "Japanese", and "Japanese (Kana)".

There is also XkbRF_GetNamesProp(), which returns a comma separated list of country codes for each group.  That could be easier to use but is deprecated because it supports only one global keyboard layout, whereas keyboard layouts can differ across devices.  We only listen to events on the "core" device (which collects from several devices) anyway, so that may be fine.

I'm not familiar with either of these.

For the IME, there I don't see to be anything relevant in GtkIMContext.  LC_CTYPE may be used to select the IME, but only when there is no explicit setting.

Comment 9

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

Attachment: part.2 Implement KeyboardEvent.locale and CompositionEvent.locale on Windows

This emulates the behavior of IE 10.

Comment 10

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

Attachment: part.3 Implement KeyboardEvent.locale and CompositionEvent.locale on Mac

However, we cannot get locale (country or area) of the keyboard layout. So, this patch sets only language code such as "en" "ja" to the locale attribute.

I'm not sure whether such incompatible feature between platforms is useful or not.

I mentioned about this issue here:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21830#c1

Comment 11

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

Thank you, karlt. Your information is very helpful.

Comment 12

[Aharon (Vladimir) Lanin]

> However, we cannot get locale (country or area) of the keyboard layout.
> So, this patch sets only language code such as "en" "ja" to the locale attribute.

BCP-47 does not mean that you have to have a country code in there. BCP-47 allows a way to include a country code, as well as script, and other things, but none of these are required. So, "en" and "ja" are perfectly good.

> I'm not sure whether such incompatible feature between platforms is useful or not.

It is useful. That on one platform the JS will get "en" and on another it will get "en-US" is not particularly pleasant, but it is within the boundaries of the spec, and dealing with it is not hard.

Comment 13

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

(In reply to Aharon (Vladimir) Lanin from comment #12)
> > However, we cannot get locale (country or area) of the keyboard layout.
> > So, this patch sets only language code such as "en" "ja" to the locale attribute.
> 
> BCP-47 does not mean that you have to have a country code in there. BCP-47
> allows a way to include a country code, as well as script, and other things,
> but none of these are required. So, "en" and "ja" are perfectly good.

However, then, adding country code isn't good on Windows. If web apps developers test the value with "==" and test the web apps only on Windows, then, the web apps don't work well on other platforms.

Comment 14

[Aharon (Vladimir) Lanin]

Couldn't that be tackled by documentation (e.g. MDN)? I would hate to lose information where it is significant just to make the feature work exactly the same on all platforms. For example, some language are written in an RTL script in some countries and in an LTR script in other countries; the same language code is used in both cases, but with a different region or script tag. If Windows gives the region tag, let's keep it.

Comment 15

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

These attributes are not defined in the latest UI Events spec.
https://w3c.github.io/uievents/#changes-drafts

The KeyboardEvent and CompositionEvent interfaces defined a locale attribute. This attribute was underspecified and moved into a technical note until it can be specified adequately. Refer to this old version of UI Events (before the DOM3Events spec was renamed "UI Events") for details.

I close this bug and maybe I'll file a new bug if they would be back with newer spec.