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: