The isChar property of event object is always false. I looked up the (sparse) documentation on isChar (http://www.mozilla.org/docs/dom/domref/dom_event_ref13.html#1003548) and it says isChar returns "a boolean indicating whether the event produced a key character or not". This is not the case - I've never seen isChar with a value of true. In any case, this is a pretty useless property, considering the charCode property.
Type stuff into the textbox to generate output.
So isChar is sometimes true on Mac (cocoa widgets only) and on BeOS. It's always false on the other platforms. There are no callers in the tree that _read_ the value -- it's write-only. I propose we drop this from the DOM interface and from the nsKeyEvent and nsTextEvent structs.
Gecko is known as DOM compliant engine, and js developers love it for this. I think the work of property must be fixed. And isChar is quite useful property. (I need it :p)
> Gecko is known as DOM compliant engine Yep. Here is the entirety of the DOM specification on key events: http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-eventgroupings-keyevents I can even quote it all for you: 1.6.3. Key events The DOM Level 2 Event specification does not provide a key event module. An event module designed for use with keyboard input devices will be included in a later version of the DOM specification. So all the key event stuff is proprietary extensions to the DOM.
Thanks a lot for information! I didn't know this.
So I take it that this is a WONTFIX?
DOM 3 Events is certainly not a recommendation yet. And you're linking to a very old draft of it. The latest draft is here http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html
I stay corrected then. But there's certainly a urge for some standardization on keyboard events.
isChar is still always false (at least on Linux here) and still not in UI Events (formerly DOM Events Level 3). https://www.w3.org/TR/uievents/ https://w3c.github.io/uievents/ I could find this useful though, because the current spec's way of doing it isn't clear. Maybe (event.key === 'Dead') ? But for example I don't see how to easily test that the user really pressed 'a' without any modifier state? Or is the 'input' event more suited for this task?
Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(Still struggling with the pain, but becoming better)Assignee
2 years ago
See Also: → 1347073
I suggested similar attribute in UI Events WG, however, it was rejected (I don't remember the detail, though). Additionally, "keypress" event shouldn't be fired when it doesn't cause any characters for compatibility with the other browsers (perhaps, only in the default event group) and "beforeinput" should be fired before "keypress" only when the key input causes some characters. So, such attribute must not be necessary in the future. However, if we support this attribute now completely, some add-ons may depend on this and we need to keep maintain this non-standard attribute. Therefore, I filed bug 1347073 to remove the attribute. (In reply to Julien Wajsberg [:julienw] from comment #10) > I could find this useful though, because the current spec's way of doing it > isn't clear. Maybe (event.key === 'Dead') ? No, unfortunately, there is no way to distinguish if the key event will cause inputting characters. > But for example I don't see how to easily test that the user really pressed > 'a' without any modifier state? Or is the 'input' event more suited for this task? If you need to check just modifier state, you can use .altKey, .metaKey, .ctrlKey and .getModifierState(). If you need to detect if the user inputs some text into an editor, you *should* use "input" because it's fired even for "paste", IME and removing text. If you need to check if the key will input some text into an editor, this is really difficult. I think that you need to wait us to implement "beforeinput" (bug 970802).
> If you need to check just modifier state, you can use .altKey, .metaKey, .ctrlKey and .getModifierState(). Yeah, but the list of possible arguments to getModiferState is huge :(
Now, UIEvent.isChar is removed completely (bug 1347073).
Assignee: nobody → masayuki
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.