Bug 120607 - changing the value of an invisible <textarea> with javascript (testcase)
Summary: changing the value of an invisible <textarea> with javascript (testcase)
Status: RESOLVED FIXED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml forms (show other bugs)
Version: 3.5
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-22 18:14 UTC by steffen
Modified: 2007-09-15 00:32 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
testcase (575 bytes, text/html)
2006-01-22 18:16 UTC, steffen
Details
Another testcase (742 bytes, text/html)
2006-07-16 03:45 UTC, Daniel Hahler
Details

Note You need to log in before you can comment on or make changes to this bug.
Description steffen 2006-01-22 18:14:58 UTC
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.
Comment 1 steffen 2006-01-22 18:16:10 UTC
Created attachment 14339 [details]
testcase

temporarily, the testcase is also online at
http://buzzinhornetz.ath.cx/tmp/konqui_textarea_bug.html
Comment 2 Thiago Macieira 2006-01-23 09:56:33 UTC
I can confirm this. 3.5.1 r500000.
Comment 3 Daniel Hahler 2006-07-16 03:43:27 UTC
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).
Comment 4 Daniel Hahler 2006-07-16 03:45:19 UTC
Created attachment 16999 [details]
Another testcase
Comment 5 Daniel Hahler 2007-03-22 20:08:54 UTC
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.
Comment 6 Candid Dauth 2007-03-25 16:44:47 UTC
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.
Comment 7 Maksim Orlovich 2007-09-15 00:32:55 UTC
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