Open Bug 322490 Opened 15 years ago Updated 2 years ago

Setting self.location.href during javascript keypress event has strange behavior.

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

defect
Not set
normal

Tracking

()

UNCONFIRMED

People

(Reporter: kai.bugzilla.mozilla.org, Unassigned)

Details

(Keywords: testcase)

Attachments

(2 files)

1001 bytes, application/xml
Details
1.20 KB, application/xhtml+xml
Details
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051205 Firefox/1.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051205 Firefox/1.5

Please see attached file.

I have an onkeypress javascript event, that is attached to an <input type=text name=wrong> field via addEventListener. This input field waits for event.keyCode==13 to set self.location.href to a self link with a special parameter.

However, if I construct the attached special case, the form is submitted instead of getting the page set via self.location.href. That means, pressing enter on the input field submits the form.

Reproducible: Always

Steps to Reproduce:
1. Load the attached file into Firefox.
2. Press ENTER in the input field.
3. The addressline changes to something with parameters "wrong=15".
Actual Results:  
"wrong=15" means, that the form was submittet...

Expected Results:  
...instead of the self.location.href with parameter "right".

There are several circumstances wich trigger the expected ("right") behavior. These are integrated as comments into the attached file. Any change alone is sufficient.

- Adding a second <input type=text> field to the form
- changing the event attachment from addEventListener to element.onkeypress
- Adding an alert between "self.location.href=..." and "return false" (note: an alert before self.location.href only shows, that the event listener is always called as expected)

I tested this on Firefox 1.5 both Windows and Linux and Firefox 1.0.7 on Windows.
Attached file testcase
You have to use event.preventDefault(); when you use addEventListener, you can't cancel the event with return false in that case.
Ok.

But why does any of the mentioned changes (second input / alert box / element.onkeypress) give me the - if I understand you right - wrong behavior?
Attached file testcase
Interesting.
There is indeed a difference there when another form control is in the form.
Adding an alert doesn't make a difference to me.
I've removed the return false in this testcase completely, since it doesn't seem to matter in the difference of behavior.
Assignee: nobody → events
Component: General → Event Handling
Keywords: testcase
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → Trunk
Ah, see:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/html/content/src/nsHTMLInputElement.cpp&rev=1.419#954
That is actually wanted behavior.
When there are more than two text controls in a form without a submit button, the form will not submit when pressing enter, that is also what IE6 does.
So that's why adding a second input tag 'works', form submission by pressing enter is then automatically suppressed.
I cancel the event now to prevent automatic form submission.

But I have to say that this is not a very self-explanatory behavior. What was the background of IE to handle only-one-input-forms special? Arbitrariness? Where is it used or is this a compatibility thing that should be dropped?

Thanks for the clarification.
Assignee: events → nobody
QA Contact: ian → events
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.