IE7 has problems with document.getElementById

[justsomeguy]

OK, see if you can figure this out, if so I'll be impressed.I've got a pretty big application that uses a lot of Javascript and AJAX. In this scenario, the page is a page for comments and change requests for a project. Clients log in and submit their comments, and people working on the project log in and can edit the comments, validate them, close them, resolve them, etc. When someone updates a comment they push a little button that changes all the static text into form fields. Here are a couple chunks that create the fields for "location" and "page":

// location  removeChildren(tr.childNodes[3]);  e = ce('input');  e.setAttribute('id', 'edit_loc');  e.setAttribute('class', 'standard_input');  e.setAttribute('className', 'standard_input');  e.setAttribute('size', 10);  e.setAttribute('maxlength', 100);  e.setAttribute('value', cur_comment.loc);  tr.childNodes[3].appendChild(e);  // page  removeChildren(tr.childNodes[4]);  e = ce('input');  e.setAttribute('id', 'edit_page');  e.setAttribute('class', 'standard_input');  e.setAttribute('className', 'standard_input');  e.setAttribute('size', 5);  e.setAttribute('maxlength', 50);  e.setAttribute('value', cur_comment.page);  tr.childNodes[4].appendChild(e);

The ce function is an alias for document.createElement. So with that code I'm creating elements with IDs edit_loc and edit_page, and assigning the values to be whatever they are for that comment. Also when the edit button is pressed the edit and delete buttons change to save and cancel. When the save button is pressed then the values are read from the fields and sent to the server with AJAX, and the row is changed from a row of fields back into a row of text. The problem shows up with IE7 when the save button is pressed. The first value I get is fine, but IE7 always indicates an error on the line after that, whatever it is, even if it's a blank line. If I change the order of the values I get, same thing, the line after I get the first value is flagged with an error. The error is "object doesn't support this property or method". I use lines like this to get the values:edit_loc = $('edit_loc').value;The $ function is an alias for document.getElementById. So if I have these two lines (with line numbers):

660	edit_loc = $('edit_loc').value;661	edit_page = $('edit_page').value;

Then the error occurs in line 661. If I format the code like this:

660	661662	edit_loc = $('edit_loc').value;663664665	edit_page = $('edit_page').value;

Then line 663 is flagged with the error, a blank line (it even indicates character 5, even though the only character on that line is a newline character). If I reverse the lines and get the page first, same thing, the line after page has an error. If I add alerts:

660	alert($('edit_loc').value);661	alert($('edit_page').value);662	edit_loc = $('edit_loc').value;663	edit_page = $('edit_page').value;

The error again is on 663, it will alert both values just fine.What the ###### is going on with IE7? I haven't tested this with IE6, and obviously it works in everything else because the code is correct. Right? Once again, IE is defying everything I learned about debugging in school. Does anyone have a clue what's up here? Any ideas to test? I'm not worried about "fixing" the code because I don't think it's broken, I'm more interested in trying to get some workaround or hack so that IE will at least submit the values to the server.

[Ingolme]

I suppose the error is on line 662, and Internet Explorer is numbering them wrong.Does $('edit_loc') have a value property?Edit: well looking better, it apparently does.Maybe cur_comment.loc is causing an error in Internet Explorer.

[justsomeguy]

The line number is correct, if I use alert statements I can verify that it's stopping where it says it is. If I do this:

	alert($('edit_loc').value);	edit_loc = $('edit_loc').value;	alert($('edit_loc').value);

I see the first alert but not the second.The code to create all the fields works fine, it will create the location field with a value like "M05L05". I see that value in the first alert box but it never shows the second.If I put a line like this:edit_loc = $('edit_loc').value && alert($('edit_loc').value);It will show the alert box, so it's not causing an error just reading the value.

[justsomeguy]

More info: - it doesn't work in IE6 either, same thing. It works in Opera, Firefox, and Safari.- there are other pages in the application that do the same thing, convert a table row of text columns into fields, press save and read the values, update server, change back to text. Those pages all work fine. The page with the error is actually the last page I made so most of the code to do that stuff was copied from the other working pages.

[jeffman]

FWIW, I had problems in the past with the old className attribute, but I don't recall what.Have you tried setting those values using dot notation instead of setAttribute?

[justsomeguy]

Yeah, same thing. If I comment out setting the class and className like it is and just set e.className the same error happens in the same place. In IE class is reserved, it's not a writable property (other than by using setAttribute).

[jesh]

Well, I just made a little test page that, I think, does something similar to what you've described and it is working (no errors) for me in IE6, IE7, and Firefox. If you've copied the code from another location (which works across the browsers), could it be something as lame as an invalid line feed character or something?Here's my test:

<html><body><table border="1"><tr><th>field</th><th>Action</th></tr><tr><td>Some Value</td><td><button id="button" onclick="edit(this)">Edit</button></td></tr></table><script type="text/javascript">function $(id){    return document.getElementById(id);}function removeChildren(node){    while(node.childNodes.length > 0)    {         node.removeChild(node.childNodes[0]);    }}function edit(button){    var row = button.parentNode.parentNode;    var data = row.childNodes[0].childNodes[0].data;    removeChildren(row.childNodes[0]);    var input = document.createElement("input");    input.setAttribute("id", "data");    input.setAttribute("value", data);    row.childNodes[0].appendChild(input);    button.childNodes[0].data = "Save";    button.onclick = function() { save(this); }}function save(button){    var row = button.parentNode.parentNode;    var data = document.getElementById("data").value;    alert(data);    removeChildren(row.childNodes[0]);    var text = document.createTextNode(data);    row.childNodes[0].appendChild(text);    button.childNodes[0].data = "Edit";    button.onclick = function() { edit(this); }}</script></body></html>

[justsomeguy]

could it be something as lame as an invalid line feed character or something?

I was considering that too, but I don't think so. I have this block:

	edit_loc = $('edit_loc').value;	edit_page = $('edit_page').value;	edit_ver_id = $('edit_ver_id').value;	edit_comments = $('edit_comments').value;	edit_res_m = $('edit_res_m').value;	edit_res_d = $('edit_res_d').value;	edit_res_y = $('edit_res_y').value;	edit_resolution = $('edit_resolution').value;	edit_fix_ver = $('edit_fix_ver').value;

No matter what order I put those statements in, it always flags the second statement with the error. The edit_res_ fields are select elements and the same error happens there, I also have some text areas and normal text fields, no matter what is first and second it always flags the second line. I also converted the file between Unix-style and DOS-style line endings and that didn't change anything.If someone wants to log in and see for themselves send me a PM and I'll see what I can set up.

[jesh]

Wow, I think you're going to hate this: Breaks in IE:

<html><head><script type="text/javascript">function dosomething(){	test = document.getElementById("test").innerHTML;	alert(test);}window.onload = dosomething;</script></head><body><div id="test">This is a div!</div></body></html>

Works in IE

<html><head><script type="text/javascript">var test;function dosomething(){	test = document.getElementById("test").innerHTML;	alert(test);}window.onload = dosomething;</script></head><body><div id="test">This is a div!</div></body></html>

Because the div has an id of "test" and the first example uses a variable name of "test" without first declaring it anywhere, it appears that IE thinks that you mean to refer to the div element when you that variable. Explicitly declaring the "test" variable before using it solves the problem.To further illustrate the utter absurdity of IE in this case, consider this:

<html><head><script type="text/javascript">function dosomething(){	alert(test.innerHTML);}window.onload = dosomething;</script></head><body><div id="test">This is a div!</div></body></html>

I came upon this blog which put me on the solution:http://vinhere0.wordpress.com/2008/04/19/o...erty-or-method/

[justsomeguy]

Good lord. There's a word I would use to describe how I feel about that but it won't let me print it here, but it starts with an "f" and ends with an "ucktarded". I looked back at the other pages and I did use different variable names for the values versus the element IDs on those pages. It still doesn't make sense to me though, this line:val = $('val').value;should get $('val').value and assign it to the variable val. Now that might overwrite the element if the people developing the browser are mentally deficient, but it shouldn't cause an error. It would cause an error if I tried to access the val element after that, but assigning should never cause an error like that.I don't know which genius decided that this would be a great thing for IE to do, but it sort of makes you wonder what would happen if your page had this in it:<div id="window"></div><div id="document"></div>Would the entire browser crash? You would never be able to access the element with id "document" because when you type document.getElementById you would get an error because the document element doesn't have that method. Unintended side-effects like this are the specific reason why these features are being removed (see register_globals in PHP, gone from PHP6). Hopefully IE8 breaks the vicious cycle of retardation, but I really doubt it.Thanks for the catch, well done. I would offer to buy you a beer, but since you're in Portland you're already drinking better than I am anyway.

[jeffman]

Is this the legacy of names outside frames and forms? They really need to clean that up in 8.

[jhecht]

You know theres an awesome plugin for MooTools i think is freaking awesome. It basically does this:Browser is any form of IE?Go to mozilla.comNever go to your page unless they get Firefox.So they're getting rid of register_globals in PHP 6? Good. There's no point to that setting except to make hacking that much easier.

[justsomeguy]

Yeah, they are finally getting rid of magic_quotes, register_global, register_long_arrays ($HTTP_POST_VARS, $HTTP_GET_VARS, etc), safe mode, the ASP-style short tags, and ereg.http://www.ibm.com/developerworks/opensour...nxw01PHP-Future