Bug Tracker

Modify

Ticket #3311 (closed bug: fixed)

Opened 6 years ago

Last modified 2 years ago

Strange, inconsistent behavior of keypress() in FF 3 and IE 8

Reported by: jestempies Owned by:
Priority: major Milestone: 1.3
Component: event Version: 1.2.6
Keywords: keypress Cc:
Blocking: Blocked by:

Description

Behavior of Esc key in an <input/> in Firefox 3 seems weird. To reproduce:

1) Create a page with:

<script type="text/javascript">
$(document).ready(function() {
   $('#test').keypress(function(e){
      this.value = e.which;
      return false;
   })
})
</script>

<input id="test"/>

2) While input is focused, press 'd' -- it shows '100' (correct)

3) Press Escape -- input is empty (wrong)

4) Press Backspace -- input shows '8' (correct)

5) Press Escape -- input shows '8' (wrong)

6) Press 'd' -- input shows '100' (correct)

7) Press Escape -- input shows '8' (wrong)

8) Press Delete -- input shows '0' (wrong)

9) Press Escape -- input shows '0' (wrong)

Behavior in Internet Explorer 8 is different, but also wrong. Escape is correctly captured as 27, but Backspace, Delete and cursor keys are not captured at all.

Change History

comment:1 Changed 6 years ago by -Sami-

After some debugging the ESC key behavior on FF3 it seems that this bug is because of changes made in [4330] to an if-clause in event.fix(event) function.

Things go wrong when charCode === 0 and keyCode has the correct value and should be used. In this case the if-clause evaluates to false and event.which isn't assigned.

Commit message of the changeset says: "Fixes bug with charCode...", but I couldn't figure out which bug this is. So I don't know what would be the correct way to fix this issue..

comment:2 Changed 4 years ago by mchuah

This is still a problem in the current version. It breaks many attempts to use the which property in keypress events, including testing for keys like tab and escape in FF.

In my own copy of jQuery, I've reverted the offending line changed in [4330] to what it was in the previous revision to fix this, and it seems to work without problem.

Can anyone indicate the intent of the change in [4330] and what it was supposed to fix, or can we change the code back to what it was?

comment:3 Changed 3 years ago by dmethvin

  • Status changed from new to closed
  • Resolution set to fixed

This problem was fixed in jQuery 1.4.3.

comment:4 Changed 3 years ago by anonymous

I am still having this problem. I am using jQuery 1.6.2 and Firefox 3.6.17. e.which returns 0.

Here is an example of code that demonstrates the problem:

<html>
<head>
<title>test</title>
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js"></script>

<script type="text/javascript">
$(document).ready(function() {
	$('#test').keypress(function(e) {
		alert(e.which);
	});
});
</script>
</head>
<body>

<form action="myaction">
<input type="text" name="test" id="test">
</form>

</body>
</html>

The result of pressing escape when the cursor is in the text field is an alert box with "0".

Please follow the  bug reporting guidlines and use  jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.

View

Add a comment

Modify Ticket

Action
as closed
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.