lemon-head, "I think not really the editor itself (TinyMCE) is the problem, but rather how the server-side filtering and processing of submitted html content conflicts with the client-side filtering."
I agree it is not really the editor its self but how it is implemented on BW. This problem has nothing to do with the HTTP Post to the server or how it handles it, as this problem occurs with no server interaction.
The problem is that the editor is generated dynamically after the page is loaded, which can be seen by how the page looks when it first arrives and then how it is afer a few seconds. I haven't looked too deeply in to this particular implementation but have used this editor in the past. Normally if you enter text into a textarea move to another page and go back in the browser, using the back button, the text you entered will still be there, unless there is some client script that is clearing the textarea, or setting it to some default value, on either, onload or onfocus page events. Because the script is either replacing the textarea with the editor or just putting it over the top and copying the content of the textarea and not subsequently updating the textarea, when you leave the page the text you have entered or modified is lost when the editor is torn down, along with the rest of that page, when the page changes. When you go back on in the case last night, forward, to that page the editor is again dynamically created and only has the original text from the textarea or supplied by a script and not the modified/new text.
From memory how I solved this issue in the past was to put the editor's html directly into the original server supplied page and not dynamically create it at onload, without some sort of workaround, as this is sure to undo any good work the browser has done in saving your work. If the positive head of steam that i had been building up hadn't been blown away by the loss, again, of a good hours work on a detailed post and response to other thread contributors, I would have time and energy to provide the client end solution to this, which a PHP head could implement. Unfortunately this event has for a while pushed my efforts to improve BW down my priority list and i have had a productive day on several for-lots-of-profit, phone calls and emails.
QuiteLost, nice beard! :) "Did any of you who have problems with losing posts try some different way of solving the problem? Other than waiting for somebody else to solve it for you, and getting frustrated in the meantime. There is for example extensions to reasonable browsers which implement autosave and recover for textareas on webpages. "Textarea Cache" for Firefox is one of them."
Genius! Yea, great solution. Rather than solving a problem at source, 13,000+ people can solve it over and over and over again at home. Lets say that takes 10 minutes to do, each, it would certainly save me the hours I wasted on writing lost posts. Lets say only 10% of the members did this, thats ~9 days of work, if everyone did it, it would be 3 months of work. To solve the issue at source would take a working day maybe, tops. Thats the kind of logic that makes my head hurt.
"this problem has been around for as long as I have used the web (well over a decade)" Its about time it was solved then. Oh wait it has been, just not on BW. I actually use another website to write, long posts, that has a spell checker and an autosave, built right in, you might have heard of gMail? This problem has had a solution for many many years. The first time i can remember solving it was 2002.
To answer you first question, yes, I started this thread, I downloaded the code and the test database, I spoke to developers in the mailing list and in the IRC chat channel. I did try before "getting frustrated". Honest!
Lets see what the developers come up with, before three months of time is spent by the human race to work around the problem, just on BW.
By continent
By category
By tag
