Closed Bug 57700 Opened 24 years ago Closed 21 years ago

changing event.keycode has no effect

Categories

(Core :: DOM: Events, defect, P2)

Product:
Core
Component:
DOM: Events
Platform:
PowerPC
Mac System 9.x
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: mikepinkerton, Assigned: kinmoz)

References

(
URL
)

Details

(Keywords: dom1, Whiteboard: [behavior])

Attachments

(3 files)

Simple Testcase.
2.59 KB, text/html
Details
Simple and self explanatory testcase.
257 bytes, text/html
Details
Auto-tab while using onkeyUP, not on keypress
1.95 KB, text/html
Details
- go to www.discovercard.com, click link to apply for a new card - click link to apply for platinum card - try really hard to enter your state, zip, or birthday as soon as you get to w/in 1 character of the max # of chars for the textfield, it will jump you to the next field automagically, putting the last char in the field it just tabbed to. THis is really really annoying when filling in forms. This works in 4.x just fine so it's not the page.
Certainly seems like there is an off by one error when the max-length is set. when set to 2, I can only type in 1 char, when set to 5, I can only type in 4 chars I would say this is a pretty bad problem, could make using a lot forms impossible
Assignee: rods → beppe
Summary: Moving to next form field too aggressive → not allowed to type in enough chars before advancing to next field
Severity: major → critical
Priority: P3 → P2
assigning to kin, however, this is not a crasher, so it won't be allowed in, and it has a workaround (as painful as it is).
Assignee: beppe → kin
Whiteboard: [rtm-]
Target Milestone: --- → mozilla0.9
No, there is no work around. You will not be able to any forms that specify max-length. This is a pretty bad bug.
Accepting bug.
Status: NEW → ASSIGNED
yeah, my workaround is to use IE.
Whiteboard: [rtm-]
Attached file Simple Testcase. —
The editor code that limits the number of characters that is inserted is fine. This an event handler ordering problem. It looks like the editor's key listener is getting called before the HTML file's KeyPress listener, so we insert the character into the TextField before the HTML file's KeyPress handler is called.
that's odd, I'm able to go back to the text input field and enter the last character, I created a form that has input type=text, with a maxlength=10, I type in 0123456789 -- all 10 values go in -- here is the code: <body> <form action="foo.html" method="put"> <input type=text name=test maxlength=10><br> <input name=next type=text> </form> </body> marking rtm- tested using MN6 builds from 2000102008 on win95 and build 20001023 on win95, and they both work just fine -- try using a mn6 build (comm)
Whiteboard: [rtm-]
Kin is correct, this is not a MAXLENGTH problem. See the attached minimised testcase, whose important contents are: <body onkeypress="event.keyCode=''"> ... <input type="text"> In IE (and I don't know if that is the correct behaviour), the keypress event effectively gets killed by the changing of event.keyCode. This is therefore only going to affect sites that do funky stuff with event objects. Lowering severity. QA: Sending over to Jan, since this is DOM related. Have fun! :-)
Severity: critical → normal
Component: Form Submission → DOM Level 1
QA Contact: vladimire → janc
Summary: not allowed to type in enough chars before advancing to next field → changing event.keycode has no effect
this sounds a lot like bug #58709
adding nsbeta1 and + for 6.5
Keywords: rtm → nsbeta1
Whiteboard: [rtm-] → [nsbeta1+]
Keywords: dom1
Component: DOM Level 1 → DOM Events
mozilla.0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
Target Milestone: mozilla0.9.1 → mozilla0.9.2
event.keycode main purpose is getting defeated here. & its top100 sites anyway. Its allready nominated for nsbeta1. Thought of adding keyword mozilla0.9.1.
Keywords: mozilla0.9.1
not my area, passing the buck to desale :)
QA Contact: janc → desale
Keywords: mozilla0.9.1, nsbeta1
Whiteboard: [nsbeta1+] → [behavior]
Updating QA contact to Shivakiran Tummala.
QA Contact: desale → stummala
Target Milestone: mozilla0.9.2 → mozilla0.9.3
could be too risky for now, moving to 1.0, if we mess up event ordering it could impact lots of things
Target Milestone: mozilla0.9.3 → mozilla1.0
*** Bug 83900 has been marked as a duplicate of this bug. ***
Bulk move of mozilla1.0 bugs to mozilla.1.0.1. I will try to pull some of these back in if I can.
Target Milestone: mozilla1.0 → mozilla1.0.1
removing myself from the cc list
Target Milestone: mozilla1.0.1 → Future
I'd like to point out that only MSIE claims to allow setting the event.keyCode. Mozilla does not. NN 4 did not allow authors to set the which property either. http://developer.netscape.com/docs/manuals/js/client/jsref/event.htm#1193156 says: "Setting any property of this object (event) requires the UniversalBrowserWrite privilege." http://lxr.mozilla.org/seamonkey/source/dom/public/idl/events/nsIDOMKeyEvent.idl#167 shows: 170 readonly attribute unsigned long charCode; 171 readonly attribute unsigned long keyCode; while in attachment 17815 [details], we can see an attempt to modify the event.which property for NN 4+ if (micID) { anchorField.value = anchorField.value + daKeypress; event.keyCode = ""; } else event.which = ""; autoTabbin = false; nextField.focus(); and in attachment 17882 [details] <body onkeypress="event.keyCode=''"> just cannot be correct. I've been using scripts to filter characters, key strokes (prevent visual display of typing of defined characters) and do an auto-tabbing in all browsers including NS 4, NS 6, Mozilla. I have huge difficulties in believing that this bug is valid. I do not see where keyCode is mentioned in DOM 1. I do not see how setting [key-]event properties was doable in NS 4. I'm all for resolving this bug as INVALID.
So based on Ian's testcase this bug is wontfix (we will not be making keycode writable). The first testcase on the bug worksforme. So does the discover site. Are there any remaining issues here?
Setting any property of the event object should/must require expanded security priviledges granted by signed scripts. "event object: Setting any property requires UniversalBrowserWrite." found at Client-Side Javascript Guide, Chapter 14, JavaScript Security http://developer.netscape.com/docs/manuals/js/client/jsguide/sec.htm#1015289
About a week or 2 before joki moved on, he told me he had a working fix for this event ordering problem in his tree, which was part of some patch that reworked how event system clients registered their listeners. He told me at the time he would be landing it within a week or two ... I'm not sure if this work actually landed or not, or if he passed this work on to those who inherited the event system ... saari, radha, or bryner?
The following code was WFM in windows ME, windows AS 2000 in MSIE 4, 5.x and in NS 6.1 some 16 months ago. It still works in recent Mozilla-based browsers. Can people using Mac os try this demo?
When trying attachment 17882 [details] with Opera 7 beta 1, the javascript console returns this: http://bugzilla.mozilla.org/attachment.cgi?id=17882&action=view Event thread: onkeypress Error: name: DOMException message: NO_MODIFICATION_ALLOWED_ERR
This bug is targeted at a Mac classic platform/OS, which is no longer supported by mozilla.org. Please re-target it to another platform/OS if this bug applies there as well or resolve this bug. I will resolve this bug as WONTFIX in four weeks if no action has been taken. To filter this and similar messages out, please filter for "mac_cla_reorg".
I can reproduce the second testcase on XP. But according to comment 23, this will not change (wontfix)?
Marking wontfix (btw, Joki's event ordering patch has landed and does not affect this bug).
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: