Last modified: 2009-11-16 21:16:36 UTC
Contrary to the way most edit boxes work in modern browsers, the edit boxes in Vector lose all my changes when I hit the back or forward button. This was especially annoying when I was hitting "back" to try to salvage my text from an edit conflict, instead of hunting for it in the big huge slow box. What I had written was simply gone.
Works fine on Chrome. FYI, this is really a browser bug
This is a bug in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=285730 We're hoping to deploy a workaround soon.
(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? 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.
(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.
*** Bug 20277 has been marked as a duplicate of this bug. ***
The same problem appears in Opera (9.64), so it's not just Firefox. For what it's worth, I never had this problem with the old skin.
and Safari 4.
*** Bug 20294 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > 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. > This was done in r55247, I'll try to get it deployed.
(In reply to comment #9) > (In reply to comment #4) > > 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. > > > > This was done in r55247, I'll try to get it deployed. > Fix is live.
(In reply to comment #10) > Fix is live. > I still have the same problem with both Opera and Firefox.
Fixed in Safari 4 it seems.
*** Bug 21537 has been marked as a duplicate of this bug. ***
