https://bugzilla.wikimedia.org/show_bug.cgi?id=20221
--- Comment #4 from Roan Kattouw <[email protected]> 2009-08-14 08:16:17 UTC --- (In reply to comment #3) > (In reply to comment #2) > > This is a bug in Firefox: > > https://bugzilla.mozilla.org/show_bug.cgi?id=285730 > > It is arguable whether it is a bug or "feature". This has been the case going > back to Firebird and older Mozilla. If you mess with a form's DOM (I think the > simplest case, is to change element names, or add/remove elements), it is no > longer the same form, so why should it be treated as such? It's only triggered by adding form fields above the affected ones, because Mozilla stupidly uses field indexes instead of field names to restore stuff, (which means it'll try to restore the textarea's content into the <select> for headers, if I interpret the bug correctly). This also means fields above the first dynamically added one do get restored correctly, which in turn means Mozilla does seem to think that it's the same form. Also, in Chrome this just works. > You'd have the same > lack of textarea-memory when creating a dyamic form from scratch in javascript > after document load. > > IMHO, the best solution is to not mess with the form using javascript (or, > show/hide existing elements, or if you are needing to be dynamically creating > elements, create them *outside* the <form>, then it works fine), then it > simply > works in Firefox. Remember, Vector is for usability, and if this is "broke" in > every current version of Firefox, then it isn't usable. > Like I said, we are working on a workaround, which involves replacing the dynamically created <select> by something else. I'll ask Trevor what the status of that is. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
