Insert should generate unique IDs when inserting new data: "In this process, nodes of type xsd:ID are modified to remain as unique values in the instance data." [http://www.w3.org/TR/2006/REC-xforms-20060314/slice9.html#action-insert]
There is something slightly wicked about this: If the types are set via a schema, then rebuild needs to have run for the types to be set (bug 338823). That's mighty fine, if it were not for deferred actions. Then we have to defer the updating of newly inserted nodes until rebuild actually runs (and before recalculate, or new values will not be used). Ouch. I might do a follow up bug for that one.
Created attachment 223794 [details] [diff] [review] Work in progress I'm not sure it's ready. It could be, but gotta go now.
There's a couple of unknowns about how this should be done (at least for me): http://lists.w3.org/Archives/Public/www-forms/2006May/0174.html I might do a some-of-the-way patch for 0.6 though.
Created attachment 223909 [details] [diff] [review] Patch It would be a good feature to have in 0.6, so here's a patch that "assumes" a few things for the questions in comment 5: 1) the id modification happens between rebuild and recalculate 2) the id is not necessarily unique, but for 99.9% of the cases it is. I use "moz-xf-id" as a prefix to not clash with XSL-generated IDs. 3) modification does not adhere to the readonly MIP (just as calculate does not either) 4) deferred actions are not handled Codewise I have two issues: 1) I'm a bit unsigned about the pointer conversion. It should be alright, but I'm not 100% sure. 2) I'm pondering massaging the node directly through nsINode instead, to avoid all the DOM calls, but then again, it's better to rely on the DOM calls. If you are ok with the assumptions, I'll post a follow up bug for fixing them / assuring that they are correct.
Comment on attachment 223909 [details] [diff] [review] Patch clearing review request... the modification might happen during the cloning, not after....