317155 - Incorrect event target element (submit instead of form) when submitting a form via accesskey (access key) or ENTER key

Status: NEW

(Core :: DOM: Events, defect, P5)

Description

[Andy Skelton]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

<html><head><title>Test</title></head><body>
<form id="post"><input type="text" id="title" value="Default" />
<input type="submit" id="save" accesskey="p" /></form>
<script type="text/javascript">
document.getElementById("post").onsubmit=function(e){alert(e.target.id);}
</script></body></html>

In 1.0.7, submitting this form with Alt+p alerts "post". 1.5rc3 alert "save". This is a change of behavior which may or may not be correct.

Submitting with click alerts "post" in both cases.

Submitting with Enter alerts "title" in both cases.

Reproducible: Always

Steps to Reproduce:
1. Make an html file from the code above
or add an accesskey attribute to a submit element
2. Have some js that depends on the form being the submit event target
3. Submit with the accesskey or Enter.

Actual Results:  
Alert "save" (the id of the submit element)

Expected Results:  
Alert "post" (the id of the form)

The script that brought this to my attention is TinyMCE (http://tinymce.moxiecode.com) a Javascript WYSIWYG editor. It assumes the event target is the form and tries to clean up the form elements on submit. Clearly it needs to check tagName and if not FORM, find the nearest FORM ancestor, not to assume anything. I'm patching my instance of the editor because Enter also breaks the script. I just wanted to be sure that this change of behavior was intended for 1.5.

Comment 1

[Andrés G. Aragoneses]

I can reproduce the bug and it's also reproducible using the ENTER key, not only the accesskey. I will add a testcase.

It's not consistent that the target of the event changes depending on the way the the submit button is activated. Besides, IE's behaviour is to have always the form be the target of the event when we use the onsubmit event.

It's possible that this bug has something related to bug 295340, but it's not the same because in the other bug they claim to use the ENTER key when the focus is in a textbox, not in the submit button.

Changing the component to Core|Dom:Events because SeaMonkey is affected too.

Comment 2

[Andrés G. Aragoneses]

Attachment: Testcase

Comment 3

[Patrick H. Lauke]

this does indeed appear to be a different facet of the same problem described in bug 295340

Comment 4

[Andrés G. Aragoneses]

Comment on attachment 204446 [details]
Testcase

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<HTML xmlns="http://www.w3.org/1999/xhtml" xml:lang="es"><HEAD><TITLE>testcase</TITLE>
    <META content="Andrés Gómez Aragoneses [knocte]" name="author"/>
    <SCRIPT type="text/javascript">
	function MyFunction(event){
	  alert("tagName of the target element is: "+ event.target.tagName);
	  event.preventDefault();
	}
    </SCRIPT></HEAD><BODY>If you click the button with the mouse, the target is the form.
    But if you submit the form with the ENTER key (adjusting the focus
    with the TAB key) or you press the accesskey (ALT+P), the target is the
    button (input).

  
    <FORM onsubmit="MyFunction(event);">
      <INPUT type="submit" accesskey="p" name="btn" id="btn"/>
    </FORM>
  </BODY></HTML>

Comment 5

[Andrés G. Aragoneses]

Attachment: Testcase

Found a typo on the last testcase. Sorry for the last useless comment/input.

Comment 6

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.