Cross browser handling special chars with keypress/keyup listener

Discussion in 'Javascript' started by Gregor Kofler, Oct 7, 2009.

  1. 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


    --
    http://www.gregorkofler.com
    Gregor Kofler, Oct 7, 2009
    #1
    1. Advertising

  2. Gregor Kofler

    David Mark Guest

    On Oct 7, 2:26 pm, Gregor Kofler <> wrote:
    > 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).
    David Mark, Oct 7, 2009
    #2
    1. Advertising

  3. David Mark meinte:
    > On Oct 7, 2:26 pm, Gregor Kofler <> wrote:
    >> 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.

    >> 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. ;)


    Precisely.

    >> 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.


    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 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).


    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


    --
    http://www.gregorkofler.com
    Gregor Kofler, Oct 7, 2009
    #3
  4. Gregor Kofler

    David Mark Guest

    On Oct 7, 6:21 pm, Gregor Kofler <> wrote:
    > David Mark meinte:
    >
    > > On Oct 7, 2:26 pm, Gregor Kofler <> wrote:
    > >> 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. ;)

    >
    > >> 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.  ;)

    >
    > Precisely.
    >
    > >> 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.

    >
    > 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).

    >
    > >> 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).

    >
    > 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.
    David Mark, Oct 7, 2009
    #4
  5. David Mark meinte:

    >> 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?


    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 &auml; &ouml; 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]
    >> 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.


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

    Gregor


    --
    http://www.gregorkofler.com
    Gregor Kofler, Oct 8, 2009
    #5
  6. Gregor Kofler

    David Mark Guest

    On Oct 7, 7:31 pm, Gregor Kofler <> wrote:
    > David Mark meinte:
    >
    > >> 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?

    >
    > 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).

    >
    > > 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 &auml; &ouml; 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. :)

    >
    > > 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.


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

    >
    > [snip]
    >
    > >> 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.

    >
    > 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.
    David Mark, Oct 8, 2009
    #6
  7. David Mark meinte:
    > On Oct 7, 7:31 pm, Gregor Kofler <> wrote:


    >> 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. :)


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

    >>> 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.

    >
    > 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".

    >> 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.


    Hooray. Ok, filed.

    Gregor


    --
    http://www.gregorkofler.com
    Gregor Kofler, Oct 8, 2009
    #7
  8. On Wed, 07 Oct 2009 20:26:48 +0200, Gregor Kofler wrote:

    > 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
    / \
    Matthias Watermann, Oct 8, 2009
    #8
  9. 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.

    >> 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?


    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

    --
    http://www.gregorkofler.com
    Gregor Kofler, Oct 8, 2009
    #9
  10. 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



    --
    http://www.gregorkofler.com
    Gregor Kofler, Oct 8, 2009
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Chris Calhoun
    Replies:
    1
    Views:
    276
    Jim Cheshire [MSFT]
    Oct 10, 2003
  2. M.Posseth

    receiving ??? chars instead of "special" chars

    M.Posseth, Nov 15, 2004, in forum: ASP .Net Web Services
    Replies:
    3
    Views:
    226
    Dan Rogers
    Nov 16, 2004
  3. George Hester

    keyup keydown Netscape > 4.x

    George Hester, Jan 15, 2004, in forum: Javascript
    Replies:
    2
    Views:
    110
    George Hester
    Jan 16, 2004
  4. Andrew DeFaria
    Replies:
    28
    Views:
    401
    Andrew DeFaria
    Jun 9, 2004
  5. cron
    Replies:
    8
    Views:
    660
    Thomas 'PointedEars' Lahn
    Oct 13, 2011
Loading...

Share This Page