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.
Please check this HTML instead of the attached URL.
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
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 → ---
(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...
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-
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
Bug 234455 fixed this. I've filed bug 330002 on eliminating GetEventTargetContent altogether if we can.
Status: NEW → RESOLVED
Last Resolved: 14 years ago → 13 years ago
Resolution: --- → FIXED
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.
You need to log in before you can comment on or make changes to this bug.