295340 - Pressing ENTER in textbox fires onsubmit event with incorrect target.

Status: VERIFIED FIXED

(Core :: DOM: Events, defect)

Description

[Tietew]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; ja-JP; rv:1.7.8) Gecko/20050511
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; ja-JP; rv:1.7.8) Gecko/20050511

When a ENTER key in a textbox is pressed just after some text is entered to the
textbox, form's onsubmit event is fired with event.target == THE_FORM instead of
THE_TEXTBOX.


Reproducible: Always

Steps to Reproduce:
1. Views attached URL.
2. Enter some text to the textbox.
3. Press ENTER key.

Actual Results:  
The alertbox says, "form".

Expected Results:  
The alertbox should say, "textbox".


After the alertbox say "form", it says "textbox" when ENTER is pressed.

Comment 1

[Tietew]

Attachment: reappearance html

Please check this HTML instead of the attached URL.

Comment 2

[Tristor]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050524
Firefox/1.0+

When using the attached testcase, I entered the text "test" and hit enter to
submit, I got a javascript dialog saying "form" hit enter again, and the dialog
disappeared, no other dialogs appeared afterwards.  If this is the incorrect
behavior (I am not understand the report fully), then this should be moved to
Core, where in Core, I don't know at the moment.

Comment 3

[Uri Bernstein]

The target of the OnSubmit event is the form, not the textbox (It's the form
being submitted, not the textbox).
Therefore the current behaviour is correct. ==> INVALID.

Comment 4

[Tietew]

No, This seems to be incorrect behavior.

Reason:  (cursor is in textbox always on hitting ENTER)
1) When I hit ENTER key WITH NO TEXT IN TEXTBOX, alertbox says "textbox".
2) When I hit ENTER key first time after I entered some text to textbox,
   alertbox says "form".
3) When I hit ENTER key second time just after alertbox says "form",
   alertbox says, "textbox".

These behavior is inconsistent.

Comment 5

[Daniel Pehrson]

(In reply to comment #3)
> The target of the OnSubmit event is the form, not the textbox (It's the form
> being submitted, not the textbox).
> Therefore the current behaviour is correct. ==> INVALID.

I'd like to see this bug reopened, the submitter is correct in that this is an
inconsistent behavior, however he has his understanding of what is 'correct'
wrong I think.

I've made a test case here:
http://dpehrson.weblinc.com/firefox/bugs/form-submit-event-wrong-target.html

If you have a submit listener attached to a form, and you submit that form, no
matter how you do it the event handler should receive the FORM as the
event.target, not the element  you had focused to submit it. With submit buttons
firefox works as expected, the problem is if you hit enter while in a text box
then the text box is passed to the submit handler as the event.target this is
not right. To make it even weirder, as noted in the original bug report, if you
change the value of the text box and THEN hit enter the form is properly passed
as the event.target, this is not good.

In summary: Hitting enter in a text box should cause a form submit, and the FORM
should be passed to the handler as event.target always, not the text box you hit
enter in.

Comment 6

[Boris Zbarsky [:bzbarsky]]

So the problem here is that nsEventStateManager::GetEventTargetContent (which is
what the event uses to get its target the first time) uses mCurrentTargetContent
in preference to asking the preshell.  Since submit events get DOM-only
dispatch, they affect the preshell's current event target, but not the
mCurrentTargetContent in the ESM...

Perhaps pushing event info in the presshell should null out the
mCurrentTargetContent in the ESM (and popping should restore the old value)?  Or
perhaps the ESM should ask the presshell for the current event target before
using mCurrentTargetContent?

Comment 7

[Boris Zbarsky [:bzbarsky]]

I think we should really fix this for 1.8; having the wrong event target on
events is pretty bad...

Comment 8

[Asa Dotzler [:asa]]

when did this regress? did we ship this problem in 1.0?

Comment 9

[Boris Zbarsky [:bzbarsky]]

Unclear, actually.  A lot of this code has changed since 1.0, but we might have
had the same problem then.

Comment 10

[Boris Zbarsky [:bzbarsky]]

More to the point, there are several simple ways to fix this particular bug; I
just don't know why this code was written this way to start with and all I'm
looking for is some information on that...

Comment 11

[Asa Dotzler [:asa]]

not in 1.0.7. not a blocker.

Comment 12

[Patrick H. Lauke]

the problem still exists in 1.5 final - when submitting via keyboard (either hitting enter on the submit button or the text input) the event target is the input, where it should really be the form (as is the case when submitting by mouse click on the submit button)

Comment 13

[Boris Zbarsky [:bzbarsky]]

Yes, the problem is not likely to go away until this bug is fixed.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Bug 234455 fixed this.  I've filed bug 330002 on eliminating GetEventTargetContent altogether if we can.

Comment 15

[Cyrille VIVION]

Using firefox 1.5.06 on Fedora core 5 on one workstation and Firefox 1.5.06 on Windows 2000 SP4 on another one, I encountered the problem as described in comment 4. Is the status should be really Resolved Fixed ?

Comment 16

[Boris Zbarsky [:bzbarsky]]

Yes.  It's fixed on trunk.  Firefox 1.5.0.x is using the 1.8.0.x Gecko branch; if it were fixed there the bug would have the appropriate keyword on it.