Closed Bug 416227 Opened 16 years ago Closed 16 years ago

event.charCode in keypress handler has unexpected values on Mac for Ctrl with chars in "[ ] _ \"

Categories

(Firefox :: Keyboard Navigation, defect)

Product:
Firefox
Component:
Keyboard Navigation
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
RESOLVED DUPLICATE of bug 432951

People

(Reporter: eric.promislow, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11

Given this code:

function dokeypress(event) {
    dump(event.charCode + "\n");
}

...

<input type="text" id="name" value="" 
   onkeyup="livehack();" onkeypress="dokeypress(event);"/>

On Linux and Windows, typing a character with the control key
down in the "name" field results in event.charCode having the
value of the bare character's ASCII code.  For example, ctrl-a =>
97

On a U.S. keyboard on an English/US Mac I've seen inconsistencies
compared to Linux/Windows behaviour with the following four characters:

Ctrl+[   L/W: 91    Mac: 27
Ctrl+]   L/W: 93    Mac: 29
Ctrl+-   L/W: 45    Mac: 31
Ctrl+\   L/W: 92    Mac: 28

Note that ascii("-") = 45, but
ascii("_") = 95, and 31 + 64 = 95.
So the charCode reflects the shifted
version, whether the shift key is down or not.

On Safari, event.charCode in keypress handlers
always gives the lower value.  For example,
Ctrl-a => 1.

I'm not sure what the correct behavior should be,
but I have to work around the inconsistency between
Windows/Linux and OS X.
I've only seen this problem with the fo

Reproducible: Always

Steps to Reproduce:
1. Write a small web page with the above code.
2. Put the focus in the text box.
3. Press Ctrl keys.
Actual Results:  
Given above.

Expected Results:  
I expected to see the same values for all three
platforms, but Safari through me off, so I don't
know what to expect now.

Should event.charCode be the same across all three
platforms?

Or should it be consistent with Safari?

Or are all bets off on cross-platform
cross-application compatibility with this
behavior?

This standalone file can be used to reproduce the problem:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Keypress Sample</title>
<script type="text/javascript">
//<![CDATA[
function dokeypress(event) {
  document.getElementById('result').value = event.charCode;
}
//]]>
</script>
<style type="text/css">

body {
    color: #036;
}
#form-items {
    border: 1px solid #DEDEDE;
    width: 550px;
}

#name {
    width: 160px;
    border: 1px solid #CDCDCD;
    background-color: #EFEFEF;
    color: #036;
}
</style>
</head>
<body>
<h2>Keypress Sample</h2>
<form id="test-form" onsubmit="return hack()">
  <div id="form-items">
      <label>Type a character:
          <input type="text" id="name" value="" onkeypress="dokeypress(event);"/>
      </label>
  </div>
  <div id="wrap-result">
    <p>txt{{<input type="text"  id='result' ></input>}}</p>
  </div>
</form>
</body>
</html>
Build ID: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008051202 Firefox/3.0
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008051202 Firefox/3.0

Confirmed for under FF3-RC1/OSX10.5.2.

If only for extension portability, shouldn't the Mac build follow Windows/Linux behavior?
More data points:

On Windows Safari, none of the above four keystrokes trigger
the event handler.  They either change the font size, or go 
to the previous or next window.

On IE 7, Ctrl-plus and Ctrl-minus change font size, and
while Ctrl-[ and Ctrl-] are handled by the above handler,
the IE model is different, and event.charCode => undefined.
You have to use the keyCode property of the event object.  Neither
is in the DOM spec.

Given that web developers still have to sniff out which browser
is being used, it makes more sense to me to be consistent within
the software, rather than to follow another web app.  

+1 on extension portability, but also for 
apps built on the Mozilla platform.  In Komodo we have to query
the current platform to do the right thing in this area.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.