Cross browser handling special chars with keypress/keyup listener

[Gregor Kofler]

The problem:
German keyboard with umlaut-keys and a "suggest" widget. Listeners for
the keyup event will fail - at least - on Opera for the umlaut-keys,
since those keys produce a keypress event, but no keyup (tested here [1]
and in my application).
Resorting to the keypress event I face another problem: Say somebody
types "foobar" and marks "bar" then presses "x". The resulting string
sent to the server for getting suggestions should be "foox", however
keypress is fired before the input element gets modified and something
like "foobarx" (element.value + String.fromCharCode(eObj.charCode)) sent.
With browser firing both keypress and keyup a combination of both
listeners will do the trick easily (get keycode/charcode in "press" and
sent in "up"). But with Opera - lacking the keyup - event, I'm stuck. I
could check for an existing selection and rebuild the string with
element value sans selected text plus typed character. But this seems
less than elegant. Any ideas for a better solution?

An old version of the widget is here [2]. It's just facilitating
keydown/keyup, but it helps to illustrate the issue.

Gregor

[1]
http://www.w3.org/2002/09/tests/keys.html
[2]
http://vxjs.gregorkofler.com/index.php?page=autosuggest

 

[David Mark]

The problem:
German keyboard with umlaut-keys and a "suggest" widget. Listeners for
the keyup event will fail - at least - on Opera for the umlaut-keys,
since those keys produce a keypress event, but no keyup (tested here [1]
and in my application).
Resorting to the keypress event I face another problem: Say somebody

The keypress and keyup/keydown events are apples and oranges.

types "foobar" and marks "bar" then presses "x". The resulting string
sent to the server for getting suggestions should be "foox", however
keypress is fired before the input element gets modified and something
like "foobarx" (element.value + String.fromCharCode(eObj.charCode)) sent.

That's not going to work unless they are at the end of the
selection.

With browser firing both keypress and keyup a combination of both
listeners will do the trick easily (get keycode/charcode in "press" and
sent in "up").

Not sure what that last bit means.

But with Opera - lacking the keyup - event, I'm stuck. I
could check for an existing selection and rebuild the string with
element value sans selected text plus typed character. But this seems
less than elegant. Any ideas for a better solution?

Yes, settimeout (give the browser a chance to catch up).

 

[Gregor Kofler]

David Mark meinte:

The problem:
German keyboard with umlaut-keys and a "suggest" widget. Listeners for
the keyup event will fail - at least - on Opera for the umlaut-keys,
since those keys produce a keypress event, but no keyup (tested here [1]
and in my application).
Resorting to the keypress event I face another problem: Say somebody

The keypress and keyup/keydown events are apples and oranges.

I could perfectly live with up/down alone, however Opera doesn't fire an
"up". Midori (and others?) on the other side doesn't fire a keypress
event at all.

That's not going to work unless they are at the end of the
selection.
Precisely.


Not sure what that last bit means.

I got lost, yes. Just the element value would do. (Apart from that: FF
reports a keyCode = 0 on keyup/keypress/keydown for all of those
extra-keys, hence I'd need keypress to get any information at all about
the pressed key.)

Yes, settimeout (give the browser a chance to catch up).

There's of course a timeout already present, so that the request doesn't
fire immediately after a keyup. If we stick to the culprit (i.e. Opera),
well... wait.

Hmmm, start the timeout with keypress, flagging for browsers sans
keypress to do that upon keyup), after timeout collect element value (do
some redundancy checks), submit. Sounds simple - makes me wonder why I
have been poring over some obscure workarounds. I'll look into it
tomorrow, see whether I have overlooked someting.

Gregor

 

[David Mark]

David Mark meinte:

The problem:
German keyboard with umlaut-keys and a "suggest" widget. Listeners for
the keyup event will fail - at least - on Opera for the umlaut-keys,
since those keys produce a keypress event, but no keyup (tested here [1]
and in my application).
Resorting to the keypress event I face another problem: Say somebody

The keypress and keyup/keydown events are apples and oranges.

I could perfectly live with up/down alone, however Opera doesn't fire an
  "up". Midori (and others?) on the other side doesn't fire a keypress
event at all.

Doesn't fire a keypress at all for what? A general rule of thumb is
that if the key pressed results in a change in the value (or
selection), deal with it in keypress. Otherwise (e.g. tab, arrows),
use keyup/down. I don't know what these German characters are, so I
can't help further with that.

And if you mean this Midori thing has no keypress event at all, you
know how to detect that.

I got lost, yes. Just the element value would do. (Apart from that: FF
reports a keyCode = 0 on keyup/keypress/keydown for all of those
extra-keys, hence I'd need keypress to get any information at all about
the pressed key.)

But I bet the charCode property has it in keypress (assuming it is not
a control character).

There's of course a timeout already present, so that the request doesn't
fire immediately after a keyup. If we stick to the culprit (i.e. Opera),
  well... wait.

No time, sorry.

Hmmm, start the timeout with keypress, flagging for browsers sans
keypress to do that upon keyup), after timeout collect element value (do
some redundancy checks), submit. Sounds simple - makes me wonder why I
have been poring over some obscure workarounds. I'll look into it
tomorrow, see whether I have overlooked someting.

Often it is the simplest solution that eludes us.

 

[Gregor Kofler]

David Mark meinte:

Doesn't fire a keypress at all for what?

Midori: No keypress for any key, either printable or not.

A general rule of thumb is
that if the key pressed results in a change in the value (or
selection), deal with it in keypress. Otherwise (e.g. tab, arrows),
use keyup/down. I don't know what these German characters are, so I
can't help further with that.

They are ä ö etc. Printable. Opera: keydown, keypress. No keyup.

All other tested browsers fire down, press, up. Though quite a few of
them provide 0 as keycode for all the different keys.

And if you mean this Midori thing has no keypress event at all, you
know how to detect that.

Indeed. And iPhone 's the same.

[snip]

No time, sorry.


Often it is the simplest solution that eludes us.

The browser inconsistencies with key events must have clouded my mind...

Gregor

 

[David Mark]

David Mark meinte:



Midori: No keypress for any key, either printable or not.

Printable is an apt description. I realized after I posted that I
gave an inconsistent description (e.g. sometimes the arrow keys change
the selection--I was thinking of something I did with the up and down
arrows in text inputs).

They are ä ö etc. Printable. Opera: keydown, keypress. No keyup..

That's a bug in Opera. If you need to support those characters (and
Opera), you'll need keyup.

All other tested browsers fire down, press, up. Though quite a few of
them provide 0 as keycode for all the different keys.

....in the keypress event for unprintable characters. That's a
cue.

Indeed. And iPhone 's the same.

That's not unsurprising. No keydown/up either, of course; so not
quite the same.

[snip]

No time, sorry.  

Often it is the simplest solution that eludes us.

The browser inconsistencies with key events must have clouded my mind...

There's a pattern if you look closely (except for IE of course). You
seem to have found a bug in Opera.

 

[Gregor Kofler]

David Mark meinte:

...in the keypress event for unprintable characters. That's a
cue.

If they *were* unprintable. But FF (3.5) gives keycode 0 for all ä, ö,
ü. At least the charCode is there.

That's not unsurprising. No keydown/up either, of course; so not
quite the same.

Haven't had a chance to test it, yet. It's just that quirksmode lists
keyup, keydown as "ok" and keypress as "no".

There's a pattern if you look closely (except for IE of course). You
seem to have found a bug in Opera.

Hooray. Ok, filed.

Gregor

 

[Matthias Watermann]

The problem:
German keyboard with umlaut-keys and a "suggest" widget. Listeners for
the keyup event will fail - at least - on Opera for the umlaut-keys,
since those keys produce a keypress event, but no keyup (tested here [1]
and in my application).

That doesn't look like your "problem" but (part of) an analysis to track
down some unknown problem. So what's your goal? For what purpose do you
think you need those events?

Resorting to the keypress event I face another problem: Say somebody
types "foobar" and marks "bar" then presses "x". The resulting string
sent to the server for getting suggestions should be "foox", however
keypress is fired before the input element gets modified and something
like "foobarx" (element.value + String.fromCharCode(eObj.charCode))
sent.

It looks like you're trying to do some kind of input validation, right?
Well, in such a situation I usually involve two event handlers: the
keyPress to check if a given character is allowed and Change to check
if the overall input follows a given pattern. So the former would
test the "x" of your example and the latter would test "foox". I don't
see a situation where "foobarx" would be send by the browser.


--
Matthias
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST M$ ATTACHMENTS
/ \

 

[Gregor Kofler]

Matthias Watermann meinte:

That doesn't look like your "problem" but (part of) an analysis to track
down some unknown problem. So what's your goal? For what purpose do you
think you need those events?

I need them with my suggest widget. And since there are search terms
that incorporate or start with an /umlaut/ I need to work around the
browser issues with non ASCII characters.

It looks like you're trying to do some kind of input validation, right?

With "pure" validation I'd rather go for the blur event.

Well, in such a situation I usually involve two event handlers: the
keyPress to check if a given character is allowed and Change to check
if the overall input follows a given pattern. So the former would
test the "x" of your example and the latter would test "foox".


I don't
see a situation where "foobarx" would be send by the browser.

It isn't any more - see my other postings. But change could be an
alternative, too. I need to react to cursor keys, escape, backspace,
del, enter, too, so keyup or keydown will still be needed. And a change
doesn't necessarily need to trigger an xhr (e.g. the selected part of a
suggestion get's deleted by hitting del).

Gregor

 

[Gregor Kofler]

Matthias Watermann meinte:

It looks like you're trying to do some kind of input validation, right?
Well, in such a situation I usually involve two event handlers: the
keyPress to check if a given character is allowed and Change to check
if the overall input follows a given pattern.

I have to correct my previous posting: Change won't help at all, since
it only fires, when the input element loses its focus. With the widget
it "never" loses the focus, though.

Gregor