DOM too fast for Firebird? (long)

Developing a ridiculously dynamic form, here's a temp copy: http://www.10mar2001.com/temp/formUI/ - the scripting is in this external file: http://www.10mar2001.com/temp/formUI/formUI.js

I'd like to draw your attention to the Delete member button. It's kind of nasty what's going on back there behind the scenes, but when it's clicked, I perform these steps:
- Detect which button was clicked (by parsing its ID)
- Delete the row that button's in
- Loop over the rows in the table after the one that was deleted (including the one that takes its place)
- During the loop, rename the button so that its ID parsing will trigger the delete of the proper row (i.e., the one it's in)

This is probably just as convoluted as it sounds, but I haven't really been able to figure out a better way to provide this kind of dynamicism on a form. If you've got a suggestion, I'm open to it.

It works just fine in IE6 (I'm not trying to make it work in anything lower, just it and Firebird .7 at this point), but in Firebird, this happens:

(First, you may wish to click the Add member button a few or several times.) When you first delete a row, it's all fine and dandy, and renames the elements exactly right. The second time you click a delete button, its row is deleted, but the elements which are told to be renamed are not renamed. The third time a delete button is clicked, each button which should be renamed just loses its text, nothing more. Once a button has no text in it, if it's clicked, its row is deleted, and no renaming happens.

I have not coded this for IE. I have not coded this for *any* browser, and I believe my scripting reflects that. I have some IE-specific workarounds, because of its lack of DOM2 event use and its oddness regarding the dblclick event, but other than that, it should be perfectly fine.

Has anyone else seen this kind of thing happen in Firebird?

edited to add: Though I hadn't tried it in Opera 7 before I posted, I haven't changed a thing and it works like a freakin' charm. Why Firebird? What have I done?

Hmmm...well, it worked once for me when I deleted a row, but when I deleted a second row, it crashed the browser. I'm running Firebird 0.6.1.

...uh, ouch?

I don't think I still have .61 installed, but I'll look around and give it a shot there.

Sorry about that.


Found .60 and .61 on my system, and yes, it crashes them both. What the huh? Also crashes Mozilla 1.4, but not Netscape 7.01 (same bugs experienced). Again: What the huh?

by build date:
20021120 (Netscape 7.01) - buggy
20030516 (Firebird .6) - crash
20030529 (Mozilla 1.4) - crash
20030728 (Firebird .61) - crash
20031007 (Firebird .7) - buggy

Odd, isn't it? Time to search bugzilla.

No errors, no exceptions in moz1.5. Behaves as you described. If I were you, I'd try to avoid this clumsy method you've built, and instead rely on an array. First of all, you can use separate creation and member numbers. If you have running creation numbers, you can let the member numbers map to a creation number, and use that when you change the array.

Start with five members, for example:

[0,1,2,3,4]

Then, you delete member '2' (3rd entry) using splice.

[0,1,3,4]

Then you add three new members:

[0,1,3,4,5,6,7]

You delete 6

[0,1,3,4,5,7]

etc. That way, you easily keep track of them without having to go through each entry in the list to rename them.
Don't let the DOM do the majority of the work. Do the thinking in JavaScript, and then change only what is required in the DOM. You needn't change the ids, thay are good as they are. Use a running cretion number. However, use a member number that depends on the actual position in the members list, as specified by the array index. It's much less of a headache if you do.

I think I see what you mean, liorean, but how then when I click a button will I know which row to get rid of? In my experience, one of the most painful things to script is a walk *up* the tree from some child to some ancestor.

Basically, what I need to do is decouple the counting from the deleting. I can let my server-side processing handle the real number counting, I guess; the problem with that will be telling it when to finally stop. Regardless, I see much much difficulty in trying to figure out which row contains the delete button I just clicked.

Recommendations?

I don't see any troubles with it, really. you just do an easy traversal:function getRow(oElm){
return ( /^tr$/i.test(oElm.tagName)?
oElm:
getRow(oElm.parentNode));
}which you call with this as the argument, from the event handler. It will return your row, nice and simple.

Is it just me or does that look like it would cause infinite recursion? And are the parinthesis unmatched?

Yeah, I saw that now. Fixed as I intended it.

Okay, so it's coming along. I really appreciate your help on this.
*bows down*

I've still got to figure out which row numerically (via counter or index) was/is-to-be removed, in order to properly splice out the correct pointer in the array. What kind of trick do you have up your sleeve for that?

Simple - the button will have a running number/id taken from the creation numbering, right? Use that number/id to search through the array and splice out the one which matches the value. How best to do this will depend a little on what else you might want to use the running number, the order number, or the name.

Fantastic. I've got almost all of it figured out now.

I'm down to the more complex element creation/deletion stuff: nested sets. The demo before was very stripped down compared with what I'm actually doing. Now it's fleshed out to show the entire deal. I'll refer you to the same page (http://www.10mar2001.com/temp/formUI/) as before, with the script also in the same place (http://www.10mar2001.com/temp/formUI/formUI.js) as before.

IE 6 and Opera 7 handle the scripts seamlessly. Firebird .6 and .61 still crash.

In Firebird .7, for some reason, when the first method is deleted, its arguments stick around. No other method does this. The code that doesn't always work is this right here:
var methodSet = document.getElementById('methods').getElementsByTagName('tbody')[0],
toDelete = getRow(e.target);
methodSet.removeChild(toDelete.nextSibling); // this method's arguments
methodSet.removeChild(toDelete); // this method

I can't imagine why it would work on all but the first method. The arguments work, (AFAIK) though I'm not exactly sure why, seeing as the array indexing stuff is getting pretty ridiculous.

Any ideas?

edit: browser clarification

edit: Yes, the problem is with the nextSibling property: it doesn't want to read the ...next sibling of the row to delete. I started the week fairly fully haired; now, not so much.

final edit: All I had to do was collapse the </tr><tr> tags between the first method and its arguments, then call normalize() on the parent in the script before I tried to delete the nextSibling. I think I'm starting to get the hang of this.


Maybe.