Version: 3.5 (using KDE KDE 3.5.0) Installed from: Ubuntu Packages OS: Linux Hi, I have put up a testcase which I refer to in the following description. On the page there is an invisible <div> which includes a form with a textarea. Using Javascript I make the <div> visible and change the value of the textarea. Alas, no text is displayed in the textarea. When clicking the link for a second time, the text is displayed though.
Created attachment 14339 [details] testcase temporarily, the testcase is also online at http://buzzinhornetz.ath.cx/tmp/konqui_textarea_bug.html
I can confirm this. 3.5.1 r500000.
The problem is: If a textarea's CSS style gets changed from "none" to "" (or "block", ..) its value gets reset to the initial default value (while it gets displayed)! Your testcase hides (and displays on clicking) the surrounding DIV, while the testcase I'll upload only operates on the TEXTAREA itself. IMHO this is a quite critical bug, because it can cause data loss, e.g. when using a spell checker like http://orangoo.com/labs/?page_id=3 (clicking on "Resume editing" resets the textarea).
Created attachment 16999 [details] Another testcase
http://orangoo.com/labs/?page_id=3 seems to have worked around this bug. Hooray! I can confirm the bug still in Kubuntu's Konqueror 3.5.6.
Changing the value does even seem not to work immediately _after_ display has been set to block. A workaround would be to change it using setTimeout('...', 0); after display has been set to block. Actually, the bug also occurs when the textarea is hidden by setting its parent node to display:none, and when the textarea is created by document.createElement and then inserted somewhere in the document tree.
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