Pressing ENTER in textbox fires onsubmit event with incorrect target.

VERIFIED FIXED

Status

()

--
major
VERIFIED FIXED
14 years ago
12 years ago

People

(Reporter: tietew-bugzilla, Unassigned)

Tracking

({testcase})

Trunk
testcase
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8b5 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
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.
(Reporter)

Comment 1

14 years ago
Posted file reappearance html
Please check this HTML instead of the attached URL.
Keywords: testcase

Comment 2

14 years ago
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.
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Component: General → DOM: Events
Product: Mozilla Application Suite → Core
Resolution: --- → INVALID
Version: unspecified → 1.0 Branch
(Reporter)

Comment 4

14 years ago
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.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---

Comment 5

14 years ago
(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.
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?
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
Version: 1.0 Branch → Trunk
I think we should really fix this for 1.8; having the wrong event target on
events is pretty bad...
Flags: blocking1.8b4?

Comment 8

14 years ago
when did this regress? did we ship this problem in 1.0?
Unclear, actually.  A lot of this code has changed since 1.0, but we might have
had the same problem then.
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...
not in 1.0.7. not a blocker.
Flags: blocking1.8b5? → blocking1.8b5-

Comment 12

14 years ago
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)
Yes, the problem is not likely to go away until this bug is fixed.
Depends on: 234455
Flags: blocking1.9a1?
Bug 234455 fixed this.  I've filed bug 330002 on eliminating GetEventTargetContent altogether if we can.
Status: NEW → RESOLVED
Last Resolved: 14 years ago13 years ago
Resolution: --- → FIXED
Flags: blocking1.9a1?

Comment 15

13 years ago
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 ?
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.
(Reporter)

Updated

12 years ago
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.