21 Jan 2014

[17:05] == garykac [~[email protected]] has joined #webapps

[17:06] == kochi_home [~[email protected]] has joined #webapps

[17:06] greetings kochi-san

[17:06] <kochi_home> morning

[17:06] I'm the first one on the teleconf call.

[17:06] good morning.

[17:06] <kochi_home> hi Gary

[17:07] <kochi_home> good morning nakano-san

[17:08] ohayou minna-san

[17:08] :-D

[17:10] Travis is going to be embarrassed when he dials in and discovers that everyone else got here before he did ^_^

[17:11] We can start going through the bug list.

[17:11] Frankly, I haven't looked at it since December, but I need to start fixing the remaining bugs.

[17:11] Are there any issues in particular that people want to talk about?

[17:12] I worry about the key name or .key attribute is hard to search in souce code https://www.w3.org/Bugs/Public/show_bug.cgi?id=23943

[17:13] Additionally, some .code values are same as .key values. E.g., ScrollLock.

[17:14] <kochi_home> It's a bit away from the spec itself, but I'm concerned about https://code.google.com/p/chromium/issues/detail?id=118639

[17:14] <kochi_home> > keydown and keyup events do not have proper keyCode (it's always 0)

[17:14] <kochi_home> on Android

[17:14] <kochi_home> on Android Chrome.

[17:15] <kochi_home> Due to the Android input framework, sometimes it's hard to assign a keycode (e.g. backspace) to KeyboardEvent.keyCode

[17:16] Re: 23943, I think it's too late to change the name from 'key' to anything else since there are existing implementations. Although I agree tha the name is unfortunate. Same with 'code'. Sadly the better names like 'keyCode' were already taken.

[17:16] <kochi_home> People are complaining that the behavior is different from desktop browsers and their web app doesn't work as expected on Android

[17:16] As for the 'key' values, we did clean them up a bit and added prefixes where they made sense.

[17:17] You can't search for all the possible 'key' values since they can be any Unicode string.

[17:17] == jsbell [~[email protected]] has quit ["There's no place like home..."]

[17:19] Re: 118639: We're not addressing any of the 'keyCode' problems. This sounds like a Chrome-specific issue in any case. If Chrome Android acted just like Chrome desktop, then (I think) people wouldn't be complaining.

[17:19] kochi_home: Gecko always compute keyCode value from VK rather than scan code, doesn't that help to fix the issue?http://mxr.mozilla.org/mozilla-central/source/widget/android/nsWindow.cpp#1275

[17:21] <kochi_home> masayuki: see comment #102 of the issue above, from "MSAOfficeWebApps", Firefox seems to behave the same (they can't get keycodes for backspace either).

[17:21] == lmcliste_ [~[email protected]] has joined #webapps

[17:21] <kochi_home> (interestingly, a Microsoft program manager is reporting the issue in Chromium issue tracker :-) )

[17:22] <kochi_home> masayuki: thanks anyway, I'll look into Chrome code later.

[17:24] <kochi_home> The problem of backspace is that, some IMEs don't send key event, but they just remove surrounding text.

[17:24] <kochi_home> So we have to fabricate the backspace key event in that case, if we would have to.

[17:24] Hmm, I'll check it later.

[17:25] <kochi_home> Unfortunately (?) Android webview has such an emulation for backspace and developers looks confused that Chrome doesn't work the same way.

[17:27] garykac: If we would add prefix for key names and code values, it would be great. E.g., web apps can distinguish if a .key value is a printable key's or function key's.

[17:27] garykac: And perhaps, it can prevent simple mistakes at writing code which handles both .key and .code.

[17:27] We did add a prefix for many of the 'code' values, (eg: 'KeyA' instead of 'A') to remove ambiguity.

[17:28] I don't think we can add prefixes to 'key' at this point.

[17:28] But I understand the concern about the 'key' and 'code' values being the same (eg: for PrintScreen)

[17:28] == lmcliste_ [~[email protected]] has quit [Ping timeout: 180 seconds]

[17:28] However, I'm not sure that there's any real value in giving them different values.

[17:29] I tried to give the 'code' values different names whenever I could.

[17:29] Some were easy: (like key = ' ' vs. code = 'spacebar')

[17:30] But for CapsLock and Tab and Delete and others, it seems strange to have CapsLock and XxxCapsLock. Would we then need to have XxxSpacebar?

[17:30] Things quickly got ugly.

[17:30] == lmcliste_ [~[email protected]] has joined #webapps

[17:30] E.g., foo(event.key) and foo(event.code) could cause a bug.

[17:31] True.

[17:31] But they should already for any of the common keys. (eg: key = 'a' or 'A' vs code = 'KeyA')

[17:32] It a relatively small set of keys with specific names that share names between 'key' and 'code'

[17:33] If anyone is checking for PrintScreen (or Tab, or Delete), it probably doesn't matter if they use 'key' or 'code' since those keys don't vary based on keyboard layout.

[17:33] Ah.

[17:34] (But we should double-check that now that you mention it - we definitely don't want to share names for any keys that change based on layout).

[17:34] If anyone is using 'code' when they should be using 'key' to check for the 'a' key, they will quickly see that it doesn't work they way they expected.

[17:36] garykac: In Example 24 of current ED, .code is empty for keypress event. Is that intentionally?

[17:36] I don't think so, but let me check.

[17:37] garykac: And there are no code values for the keys in left side block of Sun keyboard.

[17:39] I'm not sure if they have specific USB Usage ID, though.

[17:39] We should add the keys for the Sun keyboard. Does 23751 track all the keys that are missing?

[17:39] I might remove the USB usageID - that's just for reference anyway and I'm not sure how useful people find it.

[17:41] re: Example 24. The keypress has an empty 'code' field because it doesn't completely make sense for 'code' to be set since the keypress event is the result of multiple keys (eg: shift + a). We could make it the value of the last key that contributed to the keypress event, but that doesn't seem all that useful.

[17:42] Bug 23751 should care "legacy" keys :-)

[17:43] == heycam has changed nick to heycam|away

[17:43] Which other ones do we need? If you can add to that bug or create a new one that would be great. I don't have a Sun keyboard to test :-(

[17:44] We'd like to cover (almost) every key that can be typed on a modern (or almost modern) keyboard.

[17:44] Okay, I'll file a bug for Sun keyboard with more information.

[17:44] The only keys I don't want to include are those that cannot be typed on keyboards anymore (eg: old Lisp machine keyboards)

[17:44] masayuki: thanks!

[17:45] Can I check USB usage ID of them? If it's possible, how?

[17:45] masayuki: just a sec. I'll send a link to the USB doc...

[17:46] Windows hides the raw code with scan code...

[17:46] http://www.usb.org/developers/devclass_docs/Hut1_12v2.pdf

[17:46] Starting on page 53 is the Keyboard section.

[17:46] == lmcliste_ [~[email protected]] has quit [""]

[17:47] The keyboard is USB usage page 0x07, but some keys are that found on newer keyboards (like Sleep) can be in the other Usage pages. But we mostly care about 0x07.

[17:49] I don't understand how to check the actual code of a key...

[17:50] You mean something like hooking up a physical keyboard to a device that will give you the USB code? (because the host OS hides that info)

[17:52] I played around with getting an Arduino to read the raw USB info from a keyboard, but didn't get it to work completely.

[17:52] Um, I want to check if the Sun specific keys share other keys in typical keyboard layout or not.

[17:54] Ah, but it should be possieble with scan code of windows or hardware_keycode of GDK, perhaps.

[17:55] MSDN has: http://msdn.microsoft.com/en-us/library/windows/desktop/ms645543(v=vs.85).aspx

[17:55] RawInput mode, which sounds like it might give the raw USB info.

[17:55] garykac: Oh, thank you. I'll check it.

[17:56] Unless someone has created a translation table, reading the raw data from the keyboard is the only way that I can think of.

[17:58] I think that's all we have for today. We should probably adjourn for now. Should we try meeting next week? or two weeks from now?

[17:59] BTW, when browser cannot set .code value with unknown key, .code should be empty string? or there is something special code value like "Unidentified"?

[18:00] Either is okay to me (1 vs 2 weeks from now)

[18:01] <kochi_home> Travis sent a mail...

[18:02] IIRC, the 'code' should be empty ('') in that case. We should mention that explicitly in the spec, however.

[18:03] garykac: thanks.

[18:04] OK. So let's try for next week. I'll hopefully have knocked out a few of the bugs and we can discuss matters from there.

[18:04] Thanks.

[18:04] <kochi_home> Thanks

[18:04] I'll send a copy of this chatlog to the mailing list.

[18:04] Okay, thank you.