Opened 13 years ago

Closed 13 years ago

Last modified 10 years ago

#2886 closed defect (fixed)

IE: default action does not occur with onkeypress listener

Reported by: guest Owned by: sjmiles
Priority: high Milestone:
Component: Events Version: 0.9
Keywords: Cc:
Blocked By: Blocking:

Description

Dojo version:
profile=base, built from current development sources of 0.9, at revision 8351.
Does not occur with Dojo 0.4.2.

Browser:
IE7, Windows; IE6 should also be affected.
Does not occur with Firefox 2.0, Windows.

Problem:
In our Web application we use onkeypress listener on an input field to perform validation/filtering of the characters being entered. If the character is not correct, I suppress the default action. Otherwise, the listener does nothing, and the character appears in the text field.

The problem is that, with current development sources, the default action does not occur, the text field remains empty.

Caused by:
I suppose that this is caused by changing the value of evt.keyCode in _fixKeys function of _base/event.js (assigning a 0 to it).

Adding the following code fragment to the listener provides a workaround against this bug:

	// workaround: restores evt.keyCode zeroed by dojo
	if(dojo.isIE && !evt.keyCode && evt.charCode){
		try{ evt.keyCode = evt.charCode; }catch(x){}
	}

Please consider the following:

  1. According to DOM Events, the attributes of an event are declared as readonly. You should not try to change them.


  1. Internet Explorer allows changing the attributes (although not for all key values, see ticket #2882), but it affects the default action. Replacing the keyCode affects the character being inserted into the text field.

May be you should consider adding your own attribute or function, instead of changing the existing ones.

Best regards,
Konstantin Kolinko

Attachments (3)

keypressed_test.htm (1.4 KB) - added by guest 13 years ago.
Demonstrates the issue. Try to type anything in the text fields.
keydown_CtrlEnter_test.htm (1.6 KB) - added by guest 13 years ago.
Demonstrates Ctrl+Enter processing problem
keydown_stopEvent_test.htm (1.5 KB) - added by guest 13 years ago.
Demonstrates bad effect of clearing evt.keyCode when stopEvent() is called

Download all attachments as: .zip

Change History (19)

Changed 13 years ago by guest

Attachment: keypressed_test.htm added

Demonstrates the issue. Try to type anything in the text fields.

comment:1 Changed 13 years ago by guest

The attachment, keypressed_test.htm demonstrates the issue. With Internet Explorer, I am unable to enter anything into the first text field. The second one has the workaround applied.

Pressing ctrl or shift key in the field results in script error (see ticket #2882).

comment:2 Changed 13 years ago by sjmiles

Owner: changed from alex to sjmiles

comment:3 Changed 13 years ago by sjmiles

Resolution: fixed
Status: newclosed

Should be fixed as of [8467].

Changed 13 years ago by guest

Attachment: keydown_CtrlEnter_test.htm added

Demonstrates Ctrl+Enter processing problem

comment:4 Changed 13 years ago by guest

Resolution: fixed
Status: closedreopened

Dojo version:
profile=base, built from current development sources of 0.9, at revision 8503.

Thank you for the fix. The main issue is cured. But I encountered another one.

In IE, if onkeydown listener was attached after onkeypress one, it cannot process Ctrl+Enter, as the event.keyCode is cleared.

Using keydown_CtrlEnter_test.htm that I have attached:

  1. Put the cursor into the text field
  2. Press Ctrl+Enter

In IE7 the following messages are printed:

onkeydown_1    keyCode: 13
              ctrlKey: true
              charCode: undefined

onkeypress    keyCode: 0
              ctrlKey: true
              charCode: 0

onkeydown_2    keyCode: 0
              ctrlKey: true
              charCode: undefined

onkeypress    keyCode: 10
              ctrlKey: true
              charCode: 10

In FireFox? 2.0 the following messages are printed:

onkeydown_1    keyCode: 13
              ctrlKey: true
              charCode: 0

onkeydown_2    keyCode: 13
              ctrlKey: true
              charCode: 0

onkeypress    keyCode: 13
              ctrlKey: true
              charCode: 0

The test page has three listeners attached to the same input field, in the following order: onkeydown_1, onkeypress, onkeydown_2.

Expected result:
1) onkeydown_2 should print the same keyCode as onkeydown_1

2) Also, the first onkeypress message should either be absent, or have a non-zero keyCode or charCode

I suppose that the cause lies in implementation of _stealthKeyDown function in event.js.

I am complaining about 1), but actually it looks like 2) causes 1), as keyCode value is being copied back from keypress event into keydown one.

Workaround against 1):
Attach all your onkeydown listeners before your onkeypress ones.

Best regards,
Konstantin Kolinko

comment:5 Changed 13 years ago by guest

Further investigation shows, that 1) ("second keydown being broken") exists event for those keys where 2) ("keypress") is ok.

On the same test page, if I press Ctrl+E, the following messages are printed, in IE7:

onkeydown_1    keyCode: 69
              ctrlKey: true
              charCode: undefined

onkeypress    keyCode: 0
              ctrlKey: true
              charCode: 101

onkeydown_2    keyCode: 0
              ctrlKey: true
              charCode: undefined

In Firefox 2.0:

onkeydown_1    keyCode: 69
              ctrlKey: true
              charCode: 0

onkeydown_2    keyCode: 69
              ctrlKey: true
              charCode: 0

onkeypress    keyCode: 0
              ctrlKey: true
              charCode: 101

Expected result:
1) onkeydown_2 should print the same keyCode as onkeydown_1

Best regards,
Konstantin Kolinko

comment:6 Changed 13 years ago by sjmiles

(In [8507]) Special event handling for CTRL-ENTER on IE. Refs #2886.

comment:7 Changed 13 years ago by sjmiles

Resolution: fixed
Status: reopenedclosed

Thanks for the report.

Should be fixed as of [8507]. Special handling was needed to normalize CTRL-ENTER to Mozilla behavior.

A few minor process notes:

  • This is a new bug, please make a new ticket next time.
  • You can test keyboard stuff by connecting directly to document, you don't need any input tags and certainly not any form tags.
  • You can use console API on all browsers now, no need to write any special output code (make sure isDebug is true).
  • You can put djConfig directives directly into the dojo script tag, like so:
    <script src="/dojo/dojo.js" djConfig="isDebug: true"></script>
    

comment:8 Changed 13 years ago by guest

Resolution: fixed
Status: closedreopened

Reopening. The Ctrl+Enter mapping is fixed, but onkeydown_2 issue is still there.

Using dojo built from revision 8508.

Using IE7, if I press Ctrl+E, the following is printed:

onkeydown_1    keyCode: 69
              ctrlKey: true
              charCode: undefined

onkeypress    keyCode: 0
              ctrlKey: true
              charCode: 101

onkeydown_2    keyCode: 0
              ctrlKey: true
              charCode: undefined

Expected:
keyCode in onkeydown_2 should be 69, not zero.

Thank you for your suggestions, I will honor them next time.

Best regards,
Konstantin Kolinko

comment:9 Changed 13 years ago by sjmiles

(In [8510]) More repairs due to side-effects of trying to clear keyCode as on Mozilla. Just eliminating that part of the normalization for now, it's not necessary. Refs #2886.

comment:10 Changed 13 years ago by sjmiles

Sorry I didn't catch that before K.K., especially because you had noted it here. This is actually a third bug. It should be fixed in [8510].

Thanks again for the reports.

I will wait for you to test and mark this ticket or follow up as necessary.

Changed 13 years ago by guest

Attachment: keydown_stopEvent_test.htm added

Demonstrates bad effect of clearing evt.keyCode when stopEvent() is called

comment:11 Changed 13 years ago by guest

Found some minor ones while testing. Those will be filed separately. Here is another big one caused by zeroing the keyCode.

Dojo:
built from revision 8529, patched as described in ticket #2975

Browser: IE7

Steps to reproduce:

  1. Open keydown_stopEvent_test.htm using IE7

(note: to run it offline, you should follow ticket #2975, by patching dojo, or adjusting the browser)

  1. Put the cursor into the text field and press 'q' character key (just a single character)

In IE7 the following is printed in firebug console (omitting insignificant parts with ...)):

onkeydown_1 keyCode: 0 ... charCode: undefined ... cancelBubble: true
onkeypress keyCode: 0 ... charCode: 0 ... cancelBubble: true
onkeydown_2 keyCode: 0 ... charCode: undefined ... cancelBubble: true

In Firefox 2.0 the following is printed:

onkeydown_1 keyCode: 81 ... charCode: 0 ... cancelBubble: true
onkeydown_2 keyCode: 81 ... charCode: 0 ... cancelBubble: false
onkeypress keyCode: 0 ... charCode: 113 ... cancelBubble: false

Main issue (let's number it as (4)):
In IE7, evt.keyCode is set to 0 when stopEvent() is called. Consequently, neither this listener nor the next ones see the value. Note, that "keyCode: 0" is being printed on all the three lines in IE.

Minor issues:
(5) _stealthKeyDown generates a bogus "onkeypress" event with keyCode: 0 and charCode: 0.

(6) It is a surprise for me, that Firefox 2.0 generates a keypressed event even if the keydown one was cancelled. The IE does not generate one. Isn't it Firefox bug? What other browsers are doing? I feel like the browsers, and _stealthKeyDown method also, should not generate "keypress" event if "keydown" was canceled. Do you know the answer? Needs further (separate) discussion/investigation.

(7) I do not understand, why in Firefox case there is "cancelBubble: false" on the second and third lines. As for me, needs further (separate) investigation.

Unless you already have the answers for (6), (7), I will investigate them and file separate issues if these are problems.

Firefox version: 2.0.0.3

comment:12 Changed 13 years ago by sjmiles

Resolution: fixed
Status: reopenedclosed

Re: (4), I'm not convinced this is a defect.

Setting keyCode to 0 quite effectively clobbers the event in IE, including for your follow up handlers which should not be reacting to 0 keyCodes. The 0 keyCode should render the extraneous events harmless.

If you disagree, please open a new ticket, since the effect of stopEvent is not directly related to the original bug.

Wrt (6) and (7) it's my understanding we aren't doing any operations on those events in Dojo. If the odd effects you see are related to Dojo, then definitely file it as a defect. If you believe this is a problem Dojo should be doing something about, please file it as an enhancement.

It's good to have this stuff worked out and tested, but I wonder why you are using onkeydown at all? Afaik, onkeypress should handle the majority of situations.

comment:13 Changed 13 years ago by guest

Thank you for the explanations. I understand all that a lot better now.

I use onkeydown handler to implement some easy keyboard navigation around the web form (honoring required fields, field groups etc.), catching up/down/pgup etc. keystrokes. The onkeypress handler is used at the same time to provide input filtering.

Agreeing that the ticket is resolved.

Konstantin Kolinko

comment:14 Changed 13 years ago by sjmiles

Thanks for the excellent reports Konstantin. Please keep asking questions as things come up.

I use onkeydown handler to implement some easy keyboard navigation

Ok, but why not use keypress for that? Under Dojo, arrow keys and so on are available in IE on keypress (that's mainly what all this work is for).

comment:15 Changed 13 years ago by guest

! As of now, up and down arrows, page up, page down do not produce a keypress in Firefox 2.0, although left and right arrows do.

(Could it be the reason behind someone's ticket #2936?) You can see it using the "keydown_stopEvent_test.htm" page from above, just remove stopEvent() calls from there. In IE, all those strokes are simulated by _stealthKeyDown.


I, especially, do not like the idea of relying on keypress when trying to process the arrows and such. They are not printable, why the heck keypress is there?

Will there always be _stealthKeyDown instance shadowly connected for my keypress handlers (thus connection time cost), and never disconnecting when I disconnect them, nor providing a handle so that I can disconnect it forcefully. (Now, in IE only, but taking arrows into account, will it be in Firefox or elsewhere also?).


As of now, keydown/keyup/keypress events are not a part of any official standard. The are not in DOM 2.0 Events (see chapter 1.6.3 there).

As of upcoming DOM 3.0 Events, keyup and keydown are there, but keypress is not. It is replaced with "textInput" event (in chapter 1.7.2), providing no support for unprintable characters. Though that standard is not yet official, and is far from being implemented anywhere.

Best regards,
Konstantin Kolinko

comment:16 Changed 13 years ago by sjmiles

As of now, up and down arrows, page up, page down do not produce a keypress in Firefox 2.0

This is specific behavior of the <input> element on FF and unrelated to any processing done by Dojo. Currently, if you need to trap those particular keys on that element, you will have to use keydown.


(Could it be the reason behind someone's ticket #2936?)

Possibly, I will note it there.


I, especially, do not like the idea of relying on keypress when trying to process the arrows and such. They are not printable, why the heck keypress is there?

In the absence of any real standard, the goal was to normalize behavior to FF as much as possible.


Will there always be _stealthKeyDown instance shadowly connected for my keypress handlers (thus connection time cost)

Negligible cost.


never disconnecting when I disconnect them, nor providing a handle so that I can disconnect it forcefully.

Also, nigh zero cost.


(Now, in IE only, but taking arrows into account, will it be in Firefox or elsewhere also?).

I don't see how this is harmful.


as of now, keydown/keyup/keypress events are not a part of any official standard.

Exactly.

Note: See TracTickets for help on using tickets.