Opened 12 years ago

Closed 12 years ago

#5557 closed defect (fixed)

"<hidden>"TAG named "id" in <form>Tag(dijit.form.Form),dojo parser doesn't work (IE6)

Reported by: guest Owned by: simonjb
Priority: lowest Milestone: 1.1
Component: Core Version: 1.0
Keywords: Cc:
Blocked By: Blocking:

Description

OS : Microsoft Windows 2000 5.00.2195 Service Pack4
Web Browser(version) :InternetExplorer(6.0.2800.1106) SP1
Dojo Widget :dijit.form.Form

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

	<title>This is test page</title>

	<style type="text/css">
		@import "js/dojotoolkit/dijit/themes/tundra/tundra.css";
	</style>

	<script type="text/javascript" src="js/dojotoolkit/dojo/dojo.js"
		djConfig="isDebug:false, parseOnLoad:true"></script>
	
	<script type="text/javascript">
		dojo.require("dijit.form.Form");
		dojo.require("dijit.form.Button");
	</script>
</head>

<body class="tundra">
	<form dojoType="dijit.form.Form" name="form" id="form" method="post">
		<button id="btn_send" name="btn_send" type="button" onclick="submit();" dojoType="dijit.form.Button"  value="">Send</button>
		<input id="id" name="id" type="hidden" value="1" />
	</form>
</body>
</html>

I put TAG"<hidden>" named "id" in TAG"<form>"
then dojo parser doesn't work on IE6(SP1).
On FireFox,paser does work.
Plese fix.

Attachments (3)

test.html (824 bytes) - added by guest 12 years ago.
test_code1.png (18.8 KB) - added by guest 12 years ago.
test_code2.png (19.0 KB) - added by guest 12 years ago.

Download all attachments as: .zip

Change History (19)

Changed 12 years ago by guest

Attachment: test.html added

comment:1 Changed 12 years ago by bill

Resolution: duplicate
Status: newclosed

Native tags in forms don't work at all, see #4408.

comment:2 in reply to:  1 Changed 12 years ago by guest

Resolution: duplicate
Status: closedreopened

Replying to bill:

Native tags in forms don't work at all, see #4408.

but...,this bug happened after 2007/12/20.
It work before 2007/12/20.
To the way below,
It "parsed" on current dojo source code(on SVN).

	<form dojoType="dijit.form.Form" name="form" id="form" method="post">
		<button id="btn_send" name="btn_send" type="button" onclick="submit();" dojoType="dijit.form.Button"  value="">Send</button>
		<input id="myid" name="myid" type="hidden" value="1" />
	</form>

comment:3 Changed 12 years ago by bill

Your test case is trying to call a global function called submit() that doesn't exist. Maybe that's the problem? When you say it "doesn't work", what do you mean exactly? What do you want to happen?

comment:4 Changed 12 years ago by bill

Milestone: 1.0.3
Priority: highestnormal

comment:5 in reply to:  4 Changed 12 years ago by guest

Replying to bill:

Did you actually test the code that I had written?
Has not "why I wrote the code" understood?

My explanation might be insufficient.

This problem is neither "#4408" nor "trying to call a global function called sumbit()".

Problem is rendering of screen.

When there is "<input id='id' name='id' type='hidden'>" in "<form>",rendering of screen doesn't work.

Please,Reference attached file("test_code1.png" and "test_code2.png").

"test_code1.png" is the "first code block" of this tiket document.
"test_code2.png" is "<input id='myid' name='myid' type='hidden'>".

Do you understand?

I think,there must not be what "dojo program" gives the limitation to the name(or id) of "Native HTML tag".
How do you think?

Changed 12 years ago by guest

Attachment: test_code1.png added

Changed 12 years ago by guest

Attachment: test_code2.png added

comment:6 Changed 12 years ago by bill

Summary: "<hidden>"TAG named "id" in <form>Tag(dijit.form.Form),dojo parser doesn't work"<hidden>"TAG named "id" in <form>Tag(dijit.form.Form),dojo parser doesn't work (IE6)

Oh I see. I did run the test but didn't notice that problem. If you have an <input id='myid' name='myid' type='hidden'> tag inside the form then the button widget doesn't instantiate. And only on IE. Very strange.

comment:7 Changed 12 years ago by bill

Milestone: 1.1
Owner: set to Douglas Hays
Status: reopenednew

Doug, can you fix? In the attached testcase the Form has an id="form" parameter setting, which makes the attributeMap code call _Widget.setAttribute("id", "form"), which then does a mapNode["id"] = "form" (rather than the standard mapNode.setAttribute("id", "form"), and IE6 gets an exception. (Change the testcase to say isDebug: true and it's easier to see.)

There's a comment in _Widget.setAttribute() saying that mapNode.setAttribute() didn't work for FF2 for some reason, but maybe we need to call mapNode.setAttribute() except for FF2, and have that special code for FF2?

Also, I have no idea why this only fails when there is a hidden tag in the form. Seems unrelated but somehow it is.

comment:8 Changed 12 years ago by bill

PS: actually I'm not sure what the "correct" way is to set the id of a node; I guess id is special. I found http://www.thescripts.com/forum/thread496603.html. In any case looks like we need separate code paths for IE and FF.

comment:9 Changed 12 years ago by bill

PPS: and I guess that dojo.attr() should be handling all of this, rather than having the code in _Widget.

comment:10 Changed 12 years ago by Douglas Hays

Resolution: invalid
Status: newclosed

This is an IE form limitation. Existing form attribute names like name, id, method, action, et al should not be used as values to either name or id of any child of the form. IE creates additional form attributes for each contained child using their name/id that can conflict with the form's attributes. Here is dojo-free code that demonstrates the problem. Any previous build that "worked" before only appeared to work. In reality, the form did not have all the correct attributes, but no error was thrown.

<html>
<head>
<script type="text/javascript">
        function setid(){
                var form = document.getElementsByTagName('form')[0];
                var input = document.getElementsByTagName('input')[0];

                form['id']="form";
                alert("initial form['id'] type (should be string) = " +
                        typeof form.getAttribute('id'));

                input['id']="id";
                alert("after setting input id=id, form['id'] type (should be string) = " +
                        typeof form.getAttribute('id'));

                try {
                        form['id']="form";
                        alert("after resetting form id=form, form['id'] type (should be string) = " +
                                typeof form.getAttribute('id'));
                } catch(e) {
                        alert('ERROR setting form id=form : ' + e.message);
                        form.setAttribute('id', 'form');
                        alert("using form.setAttribute('id','form'), form['id'] type (should be string) = " +
                                typeof form.getAttribute('id'));
                }
        }
</script>
</head>
<body onload=setid()><form><input></form></body>
</html>

comment:11 in reply to:  10 Changed 12 years ago by guest

Resolution: invalid
Status: closedreopened

Replying to doughays:

This is an IE form limitation. Existing form attribute names like name, id, method, action, et al should not be used as values to either name or id of any child of the form. IE creates additional form attributes for each contained child using their name/id that can conflict with the form's attributes. Here is dojo-free code that demonstrates the problem. Any previous build that "worked" before only appeared to work. In reality, the form did not have all the correct attributes, but no error was thrown.


If it is so,"dojo.parser" might have to return the "exception error"?
Because "this problem" doesn't happen if "dojo program" is not used.

Otherwise,user cannot judge problem.
As a result, a lot of time will be spent on the investigating the cause.
How do you think?

comment:12 Changed 12 years ago by Douglas Hays

Owner: changed from Douglas Hays to bill
Status: reopenednew

Bill, I still think this is a user error. His claim that it doesn't happen sometimes is just a symptom of the form element not getting attributes set that the user thinks are set - just no exception is thrown sometimes based on order of operations. I think using an id value of id is incorrectly using a reserved word.

comment:13 Changed 12 years ago by bill

I agree that using an id value of "id" is a user error, but as per the previous comment from the user, can we throw a more descriptive exception (without bloating the code too much)?

comment:14 Changed 12 years ago by bill

Owner: changed from bill to Douglas Hays

comment:15 Changed 12 years ago by Douglas Hays

Component: DijitCore
Owner: changed from Douglas Hays to simonjb
Priority: normallowest

bill wants something fixed even though it appears to be a user error. With the recent change to _Widget.js to now set the id via dojo.attr, an exception is no longer being thrown. But now the problem is completely hidden. Here's a testcase. On IE (tested with v6), getElementById works (so the string id exists) but dojo.attr does not return the correct string value for id (but FF2 does):

<html>
<head>
<script type="text/javascript" src="../ajax/work/dojo/dojo.js" djConfig="isDebug:true, parseOnLoad:false">
</script>
</head>
<body>
<form name="myform" id="myform"><input id="id" name="id" /></form>
<button onclick="alert('id = ' + dojo.attr(document.getElementById('myform'), 'id') + ' (should be myform)')">
get form id
</button>
</body>
</html>

comment:16 Changed 12 years ago by bill

Resolution: fixed
Status: newclosed

The original problem reported in this ticket is actually no longer occurring: the Button widget instantiates correctly. So will close this ticket.

However, having a <form> which contains an element XYZ with id="id" (or some other reserved name) will cause other problems on IE, namely that dojo.attr(formNode, "id") will return a pointer to that element XYZ (rather than a string), and dojo.attr(formNode, "id", "foo") also won't work.

We could possibly add some special code to dojo.attr() to throw an exception in this case, but it doesn't seem worth it for such an unusual case.

Note: See TracTickets for help on using tickets.