News from MathTran

Just another weblog

JavaScript event handling problems

with 4 comments

For our live preview online TeX editor we would like to handle key events of a textarea. Depending on the context we want to intercept the key events and let the default action happen (i.e. a character will be inserted into the textarea or the cursor will be moved) or prevent the default action and execute our own code based on the information of the key event.

Well, little we knew of how difficult it is to get the event information you need due to various browser incompatibilities. We had to do some research on the topic and would like to share our findings here for future reference.

First of all, Peter-Paul Koch has an interesting blog entry with event compatibility tables for various browsers. There, you can already see that the key events are not all cross-browser compatible. As we are especially interested in these events, Jan Wolter’s JavaScript Madness: Keyboard Events proved to be an extremely valuable resource.

Based on the above articles we decided to use the keydown event to handle all special keys, which means keys that do not produce a character, i.e. Enter, Backspace, the arrow keys. To handle character input we use the keypress event. The keypress event object has a property which holds the character that corresponds to the pressed key or keys. This property has different names in different browsers but is available in all of them. An additional difficulty is the fact that some browsers do fire keypress events for special keys and some do not.

For jQuery, there exists a plugin called fix_events, which can be used to normalize event properties. Currently we do not use this plugin because our use would be very limited. Instead we incorporated the compatibility checks within our code.


Written by mystar22

July 21, 2008 at 4:35 pm

Posted in Uncategorized

4 Responses

Subscribe to comments with RSS.

  1. hi, i found your site via a blog comment:

    i’m interested in your extension to the jquery.fieldselection plugin. did you notice, that after replacing a selection in a textarea with scrollbars (a lot of text), after replacing the scrollposition is lost? somewhere i read, in firefox this problem was not solvable…


    September 5, 2008 at 4:17 pm

  2. Hello Robert

    No, I did not know about this problem. I’ve tried it myself and found that you’re correct. To be more precise, I’m finding that the text is scrolled so that the selection is at the bottom of the display. A nuisance.

    Thank you for letting me know about this. If you find a solution, please do let us know.


    September 5, 2008 at 6:49 pm

  3. had this problem since 2004.. now that I’m doing a bit research I see this problem solved since 2006 đŸ™‚ in FF there are 2 attributes scrollTop and scrollLeft. one has to code something like this:

    var scrollTop = txtarea.scrollTop;
    var scrollLeft = txtarea.scrollLeft;


    txtarea.scrollTop = scrollTop;
    txtarea.scrollLeft = scrollLeft;

    that does it.


    September 8, 2008 at 4:00 pm

  4. I’m currently implementing a javascript that uses the MathTran service directly. I think you might have the same problem as I did, that you don’t want to fetch a new image if the user just moves around the text-area with ie. the arrow keys, instead of typing text.

    I solved this with a simple key cache. On all keydown events I check the cache to see if the textarea changed, and then fetch the image again. Simple, and avoids the event problems altogether.

    Emil Stenström

    December 11, 2009 at 12:11 pm

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: