Version: 3.5.2 (using KDE 3.5.3, Debian Package 4:3.5.3-1 (testing/unstable)) Compiler: Target: i486-linux-gnu OS: Linux (i686) release 2.6.15-1-486 If you change the display style of textarea to 'none', its content is lost when you change it back to 'block'. If we submit the form while the textarea is still hidden, the content is sent properly. It seems to be the same error of this old bug http://bugs.kde.org/show_bug.cgi?id=49828. <html> <head> <style type="text/css"> .displayNone { display: none; } .displayBlock { display: block; } </style> <script type="text/javascript"> function writeText() { document.getElementById('myTextArea').value = "Hello :)"; } function alertText() { alert(document.getElementById('myTextArea').value); } function setDisplay(display) { document.getElementById('myTextArea').style.display = display; } function changeClass(classname) { document.getElementById('myTextArea').setAttribute('class',classname); } </script> </head> <body> <form method="post" action="../printr_post.php"> <textarea rows="5" cols="50" name="myTextArea" id="myTextArea"></textarea> </form> <ol> <li><a href="javascript:writeText();">Write some text</a></li> <li><a href="javascript:changeClass('displayNone');">Change the class to .displayNone</a></li> <li><a href="javascript:alertText();">Alert text</a></li> <li>It's ok.</li> <li><a href="javascript:changeClass('displayBlock');">Change the class back to block</a></li> <li>The content is gone :(</li> </ol> <ol> <li><a href="javascript:writeText();">Write some text</a></li> <li><a href="javascript:setDisplay('none');">Hide it</a></li> <li><a href="javascript:alertText();">Alert text</a></li> <li>It's still there.</li> <li><a href="javascript:setDisplay('block');">Set style.display to 'block'</a></li> <li>It's gone anyway :(</li> </ol> <ol> <li><a href="javascript:writeText();">Write some text</a></li> <li><a href="javascript:setDisplay('none');">Hide it</a></li> <li><a href="javascript:alertText();">Alert text</a></li> <li>It's still there.</li> <li><a href="javascript:document.forms[0].submit();">Lets submit the form</a></li> <li>It's sent properly.</li> </body> </html>
argh. Serious regression.
Created attachment 17468 [details] attaching testcase for convenience
I have a feeling it may be my fault, and it's likely related to some of the other syncing bugs...
Ugh. The troublemaker is the bizarre RenderTextArea::close call. I have no idea as to why it's there... Will annotate..
.. And that call seems to be a workaround for some QTextEdit bug, which causes us to not set initial value right.. investigating
also reported in Debian BTS at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428068 for 3.5.7 with an example of code
SVN commit 712622 by orlovich: Rework how we sync textarea contents between the DOM and the Renderer, fixing multiple bugs (losing contents on display:none, the can't-do-anything-with-selection- in-wordpress bug). This also improves compatibility with IE on handling of innerText somewhat, and that with other browsers in how we handle changes to the default value/child nodes. Unfortunately, no one does it the same way, so I chose to follow Safari since its behavior makes the most sense to me. More specifically: 1. Simplify the syncing logic by making the renderer always be definitive when it exists. 2. Change how we initialize from the defaultValue --- instead of doing it in the renderer's close (which is what causes the disappearing text bug), we update value to defaultValue when the children change. That also makes innerText work sensibly on textareas. BUG: 132844 BUG: 120607 BUG: 141457 M +27 -10 html/html_formimpl.cpp M +1 -1 html/html_formimpl.h M +16 -22 rendering/render_form.cpp M +2 -1 rendering/render_form.h WebSVN link: http://websvn.kde.org/?view=rev&revision=712622
*** Bug 151017 has been marked as a duplicate of this bug. ***
Which release will have this bugfix? I still get the same error in kde-3.5.8.
4.0.0