Summary: | changing the value of an invisible <textarea> with javascript (testcase) | ||
---|---|---|---|
Product: | [Applications] konqueror | Reporter: | steffen |
Component: | khtml forms | Assignee: | Konqueror Developers <konq-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | kde-bugzilla, maksim |
Priority: | NOR | ||
Version: | 3.5 | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: |
testcase
Another testcase |
Description
steffen
2006-01-22 18:14:58 UTC
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 |