Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Cross browser handling special chars with keypress/keyup listener

Reply
Thread Tools

Cross browser handling special chars with keypress/keyup listener

 
 
Gregor Kofler
Guest
Posts: n/a
 
      10-07-2009
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
 
Reply With Quote
 
 
 
 
David Mark
Guest
Posts: n/a
 
      10-07-2009
On Oct 7, 2:26*pm, Gregor Kofler <(E-Mail Removed)> 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).
 
Reply With Quote
 
 
 
 
Gregor Kofler
Guest
Posts: n/a
 
      10-07-2009
David Mark meinte:
> On Oct 7, 2:26 pm, Gregor Kofler <(E-Mail Removed)> 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
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      10-07-2009
On Oct 7, 6:21*pm, Gregor Kofler <(E-Mail Removed)> wrote:
> David Mark meinte:
>
> > On Oct 7, 2:26 pm, Gregor Kofler <(E-Mail Removed)> 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.
 
Reply With Quote
 
Gregor Kofler
Guest
Posts: n/a
 
      10-07-2009
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
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      10-07-2009
On Oct 7, 7:31*pm, Gregor Kofler <(E-Mail Removed)> 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.
 
Reply With Quote
 
Gregor Kofler
Guest
Posts: n/a
 
      10-08-2009
David Mark meinte:
> On Oct 7, 7:31 pm, Gregor Kofler <(E-Mail Removed)> 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
 
Reply With Quote
 
Matthias Watermann
Guest
Posts: n/a
 
      10-08-2009
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
/ \
 
Reply With Quote
 
Gregor Kofler
Guest
Posts: n/a
 
      10-08-2009
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
 
Reply With Quote
 
Gregor Kofler
Guest
Posts: n/a
 
      10-08-2009
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How to truncate char string fromt beginning and replace chars instring by other chars in C or C++? Hongyu C++ 9 08-08-2008 12:18 PM
Is faster handling hexadecimal values than handling chars? Iñaki Baz Castillo Ruby 1 04-15-2008 09:04 AM
Floats to chars and chars to floats Kosio C Programming 44 09-23-2005 09:49 AM
cross browser multipart form handling John Fereira Javascript 4 09-03-2005 03:25 PM
receiving ??? chars instead of "special" chars M.Posseth ASP .Net Web Services 3 11-16-2004 07:00 PM



Advertisments