Opened 11 years ago

Closed 11 years ago

#8907 closed defect (wontfix)

onSubmit doesnt fire in IE7

Reported by: Phil Bowles Owned by:
Priority: high Milestone: tbd
Component: Dijit Version: 1.2.3
Keywords: dijit button form onSubmit Cc:
Blocked By: Blocking:

Description (last modified by bill)

Nightly build 16/03/2009 ....

dojo.addOnLoad(function(){
		theform=dijit.byId('theform');
		dojo.connect(theform,"onSubmit",function(e) {
			console.warn("I SUBMIT!!!",e);
			e.preventDefault();
			});
	});
</script>
            
</head>
<body class="soria">

<div id="theform" dojoType="dijit.form.Form">
	<input id="text" name="dummy">
	<button dojoType="dijit.form.Button" type="submit">submit</button>
</div>

Does exactly what you'd expect in FF, Opera, Safari.

IE7 gives: "Object doesn't support this property or event" on theform=dijit....first line of function. - connect doen't seem to wire up and the form submits "normally" with a page reload.

Attachments (2)

8907.html (95 bytes) - added by bill 11 years ago.
test case w/out dojo showing how IE creates a JS object according to node's id
index.htm (6.8 KB) - added by Phil Bowles 11 years ago.

Download all attachments as: .zip

Change History (24)

comment:1 Changed 11 years ago by Phil Bowles

Bizarre - if I change the javascript variable to 'z' ie z=dijit.byId... and connect(z,... it works in all cases, including IE

Looks like the IE7 code thinks the (local) variable 'theform' is the same thing as the dijit's id...its almost as if I'd put jsId="theform" in the markup...but then it would be the RIGHT thing to do the connect on, wouldn't it?

comment:2 Changed 11 years ago by bill

Description: modified (diff)

That's very strange... the error message suggest that dijit hasn't finished loading. Maybe it's a race condition with the addOnLoad() call.

Can you attach a full test case using the attach file button? Also, is this something that regressed from 1.2?

comment:3 Changed 11 years ago by Phil Bowles

That's it....apart from the dojo requires, that was the only code, but for the record, her's one showing two cases, differing only in the name of the variable they use in the connect. one fails, one doesn't

I've seen the other discussions in earlier versions and yes, this does seem like an old bug has crept back in, but this is the first time I have used the code

<!DOCTYPE HTML PUBLIC "-W3CDTD HTML 4.01 TransitionalEN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <title>Form Builder</title>

<style type="text/css">

@import "/code/dojo/resources/dojo.css";

@import "/code/dijit/themes/soria/soria.css";

</style>

<script type="text/javascript">

djConfig = {

isDebug: true, parseOnLoad: true

};

</script>

<script type="text/javascript" src="/code/dojo/dojo.js"></script> <script>

dojo.require("dijit.form.Button"); dojo.require("dijit.form.Form");

dojo.addOnLoad(function(){

z=dijit.byId('form2'); dojo.connect(z,"onSubmit",function(e) {

e.preventDefault(); console.warn("THIS WORKS",e); });

theform=dijit.byId('theform'); dojo.connect(theform,"onSubmit",function(e) {

e.preventDefault(); console.warn("I SUBMIT!!!",e); });

});

</script> </head> <body class="soria">

<div id="theform" dojoType="dijit.form.Form">

<input id="text" name="dummy"> <button dojoType="dijit.form.Button" type="submit">theform fails</button>

</div>

<div id="form2" dojoType="dijit.form.Form">

<input id="text" name="dummy"> <button dojoType="dijit.form.Button" type="submit">z works</button>

</div>

</body> </html>

comment:4 Changed 11 years ago by Phil Bowles

Update -

if you insert var z; var theform;

in global scope (in my case between the dojo.require and the addOnLoad)

then both work!

looks like the local implicitly defined variables are clobbering something during the parse phase

comment:5 Changed 11 years ago by Phil Bowles

Programmatic behaviour is different again...NOTHING I have tried will cause IE7 to fire "onSubmit", while it works in FF etc.

The odd thingis that the Firebug LITE trace shows that when I connect to "onSubmit", the form object has the following:

submit : function(),

onReset : function(/*Event?*/ e), onExecute : function(), execute : function(/*Object*/ formContents), preamble : NULL...

(note the lack of camelCase)

and if I then connect to "submit", then it contains

onSubmit : function(/*Event?*/e), onReset : function(/*Event?*/ e), onExecute : function(), execute : function(/*Object*/ formContents), preamble : NULL,

...looks like it is wilfully doing the OPPOSITE of what I connect to...and failing to fire!

comment:6 Changed 11 years ago by bill

OK, I'll take a look, although note that I said to attach a test case *using the attach file button*... please do that next time. It's a gray button that appears under the header "Attachments".

Changed 11 years ago by bill

Attachment: 8907.html added

test case w/out dojo showing how IE creates a JS object according to node's id

comment:7 Changed 11 years ago by bill

I don't know what's going on. It seems like a weird IE behavior where it creates a strange JS object w/the ID of the DOM node... I attached a test case above showing that problem.

Not sure if there's anything we'll be able to do about it. As you said scoping things using the "var foo = " syntax will workaround the problem.

comment:8 Changed 11 years ago by Phil Bowles

Sorry about the attach - I'm new around here...message received.

the "silent" jsID creation by IE is worth remembering...and a total pain!

I now have another problem - I don't know if its related: I'm programatically creating a dijit.form.Form on the fly. I have tried about 3 different methods, e.g injecting DOM elements one by one, sticking a template into innerHTML then dojo.parsing it and in EVERY case, once the code works as expected in FF (using the workaround described here to hookup the onSubmit) the same code in IE has no attr('value') , there is nothing in it. it looks NULL

somehow the form is losing (or never getting) any attr vales from the form fields when run in IE, it's drivng me nuts! There just doesn't seem to be browser-safe way of creating a complete working dijit.form.Form at runtime...and sadly that's exactly what my project is for...so I'm 100% stumped

a "test case" will be tricky as it pulls the child / field data from a db

Changed 11 years ago by Phil Bowles

Attachment: index.htm added

comment:9 Changed 11 years ago by Phil Bowles

I have attached a test case which is running live at

http://www.clonemyblog.com/dojotestcase/

PS is there any easy way to get notified of posts here?

comment:10 Changed 11 years ago by dante

@hawkmoth - under 'preferences' in top nav, just register your username and email address in trac. (the username/password pair is from LDAP, so you must enter your email separately in trac in order for notices to go out)

also worth nothing you are connecting to onSubmit, so there is no (e) object, thus no .preventDefault() (it isn't a real DOM event) ... I think returning 'false' from a declared onSubmit would work, but you'd have to define the onSubmit as a member, and not manually dojo.connect to it, but I may be entirely off base here.

comment:11 in reply to:  10 Changed 11 years ago by Phil Bowles

Yes, that code was a hangover from the previous test...luckily does no harm as I oint want the real dom event to fire the form anyway! The poblem seems tobe some differnce in the parser behaviour between "cold" page load and dynamic call wehere IE7 is concerned...either way I just can't see how the form object has no array for the data in IE7 when it does in FF (as expected)

Thanks for the tip re notifications.

I will keep searching for my own solution / wokjaround as this feature is the very essence of my project

comment:12 Changed 11 years ago by Phil Bowles

I'm no expert, but this looks to me like #8484 and #8660 returning to haunt us - IE isn't setting attr('value') on the form

comment:13 Changed 11 years ago by bill

Could be... need to check if those widgets inside the form are actually getting created, and then also if dojo.query() can find them (see the code for getDescendants() in _Widget.js, it's just a few lines of code.

comment:14 Changed 11 years ago by Phil Bowles

I have half cracked it, but you aren't going to like the answer, it runs fairly deep. There is nasty bug in dojo.attr in IE it will NOT set an attribute whose name is "name" if you see what I mean.

ie dojo.attr(someNode,'name','myformfield') fails (silently!) every time in IE. The testcase is easy - create an input node for example, do the above on it, then console dump it. The name attribute will not be set...now that MAY (we are close to the metal here and I'm out of my depth) be due do the fact the the dojo.attr code uses 'name' as the name of the name parameter..,tricky, huh? I think the IE auto-jsID wirdness may be kicking in again where odd hings happen if the js variable has the same name as the thing its referencing

from that point, all else is "obvious" the nodes i add to my form get given a "name" attribute so the forms attr('value') can find them, in IE that doesn;'t get set, so the form getDescendants startup code (in _FormMixin) drops out early...in fact it (again obviously) returns early if the child node has no name attribaute....which in IE, none do!!!

I think this one is pretty serious as well as being a !"£$% to find for a relative newbie like me!

comment:15 Changed 11 years ago by bill

Yes, this is a tricky but known bug, see [16716]. Wherer is it that dojo.attr(node, "name", foo) is still getting called?

comment:16 Changed 11 years ago by Phil Bowles

I have to agree and disagree. dojo.attr(nonde,'name',value) does not work in IE. I have found the bug. Its in dojo.attr itself right at the end, where it tries node.setAttribute - this is known to be a problem (differently in a various version of IE which can't set an "'name' attribute.

The fix isn't easy or obvious, as the node has already been created by this time and the generally acccepted "fix" (aka dirty hack) is to create the node with the name atttribute in at already,i.e. createElement(< input name="foo"....etc). To preserve the exisitng code base, it seem like the node having its name set will need to be cloned, have the name attribute textually inserted without disturbing any other attributes and then put back into the dom in place of the old one. Not easy or nice.

Either way, dijit.form with any textbox / numbertextbox / validationtextbox etc (at least) will not work programaticaly in IE until this is fixed. I guess there aren't too many occasions when programmatic "name"s are needed (thank the lord) but anything else trying to do that at run-time is broken too.

IMHO this makes the fix quite a high priority

comment:17 Changed 11 years ago by bill

I don't see a bug. The fact that dojo.attr(nonde,'name',value) doesn't work is just a limitation.

You didn't answer my question. Where is dojo.attr(node,'name',value) being called? AFAICT no code in dijit does that.

comment:18 Changed 11 years ago by Phil Bowles

LOL. Next you will be telling me it's a "feature". yes, dojo.attr doesn't get called....but the "limitation" you described in dojo.attr prevents other interfaces from functioning as "advertised" - and that IS a bug.

One "purpose" of Dojo is to present a browser-neutral interface...it normalises the different event structures of various browsers, yet is patently fails to do so in terms of dom attributes, where it could (and should!).

If part of the "spec" is that widgets function the same programtically as declared markup, then it is a bug. Answer me this:

If I take perfectly valid "dijit-ised" markup, which funtions 100% as per spec when its part of a page, and insert it into a dijit's content at run-time and it then fails on IE because no formdata gets sent...would that be a "bug"? Personally, I'd say yes.

Also the "not in dijit" therefore not a bug is a little short-sighted - the bug is in base, which dijit relies upon. Its a fairly well-known bug, and workarounds exist.

Again if any sort of spec says that dojo.attr(... sets the attribute of a DOM node, then its a bug...because it does NOT do that if the attr is "name" in IE7. If the documentation clearly states that, then maybe I'd buy your "feature" argument. Yes, perhaps its actually just a documenatation issue. I don't want to sound rude, but when you say "feature" I hear "too hard to fix"

Let's not get into a philosophical argument, if you see no bug, then could you find the vision to see a big hole in Dojo's overall goal/promise/aim of cross-browser development?

I hope your comments don't mean that you are not going to try to fix it! You were joking, right?

comment:19 Changed 11 years ago by bill

If you want dojo.attr(node,'name',value) and/or dojo.attr(node, 'type', value) to work on nodes *after* they've been inserted into the DOM, then file an enhancement request against the HTML component, and then attach a small test case (<30 lines) to that ticket using the attach file button. I personally don't think it's worth supporting but maybe you can convince James/Eugene?.

As for your index.html test case, I looked at it, but it's quite large, over 400 lines, so it's hard to see what you are demonstrating. Our spec says that widgets function the same programatically as in declared markup. If that's not working for you I can take a look, but you need to provide a much smaller test case. And you should create a new ticket since it has nothing to do with this ticket.

However, if you are trying to create a widget programatically, you should just do new dijit.form.CheckBox({name: 'foo'}) or new dijit.form.Textarea({name: 'bar'}) ... there's no need or reason to be calling dojo.attr() at all.

comment:20 Changed 11 years ago by Phil Bowles

"...nodes *after* they've been inserted into the DOM," isn't that 99.99% of the time - and what attribute maps are ll about? when else you want to? AM I missing something?

I hear what you say about the big test case - thats why I spent 1.5 hours getting a simple website working to demo the problem in real time, but yes, its a lot to look through, I accept that.

I also hear what you say re widjets at run time...I'm appy with all that, but that's not what I'm doing. I want to create the raw MARKUP for the widget at runtime then parse it at some later point. i.e. a nice UI to layout, tweak and create validation rules for a form...then a button to cut n paste the code, so I NEED to create an "<input name="foo" dojoType="ValidationTextBox?">, insert it into my "template" for later cut n paste...then parse is so its live and I can play with it too.

The cut n paste code works fine when used later, (the browser creates the domnode from markup, dojo parses it allowing dijit to decorate it...all happy) but creating the <input name="foo" can't be done at runtime by dojo (in IE) although it can in e.g. FF and others (and works fine there too)! I hope this explains my problem!

I have made some workaround code to create a named dom element that doesn't used the (IHMO broken dojo.attr) so Im <sort of> happy that I can continue...

for the record, here's my solution, which works in all browsers: function namedElement(e,n)

{ es='<'+e+' name="'+n+'">'; console.warn("trying to create "+es+" !!!!"); try {

element = document.createElement(es);

} catch (err) {

try {

console.warn("doing the <right> thing !!!!"); element = document.createElement(e); element.name=n;

} catch(err)

{ console.warn("the dojo way !!!!"); element=dojo.doc.createElement(e); dojo.attr(element,"name",n); }

} console.warn(" node created = ",element); return element; }

(Hopefully thats shows why I DO need dojo.attr! as if it worked "properly" then the above would be two lines of cross-browser-friendly code!)

Thanks for your help so far and we will "close" this one.

comment:21 Changed 11 years ago by bill

In the sample code you've listed above you are calling dojo.attr() on a node that hasn't been inserted into the document yet (ie, there's no appendChild() call). That should work perfectly on all browsers AFAIK. You shouldn't need all the try/catches, just do dojo.create(e, {name: n}).

comment:22 Changed 11 years ago by bill

Resolution: wontfix
Status: newclosed

OK, anyway I'm going to close this as wontfix, since it's unlikely we can do anything about an IE bug where it creates weird global variables (and also since you can workaround the original problem stated by using "var").

Note: See TracTickets for help on using tickets.