Bug 132844 - [regression] [testcase] Textarea loses content when changing display style
Summary: [regression] [testcase] Textarea loses content when changing display style
Status: RESOLVED FIXED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR major
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
: 151017 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-08-23 09:07 UTC by Diogo Galvão
Modified: 2008-01-08 18:16 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
attaching testcase for convenience (1.71 KB, text/html)
2006-08-23 14:46 UTC, Germain Garand
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Diogo Galvão 2006-08-23 09:07:53 UTC
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>
Comment 1 Germain Garand 2006-08-23 14:42:57 UTC
argh. Serious regression.
Comment 2 Germain Garand 2006-08-23 14:46:36 UTC
Created attachment 17468 [details]
attaching testcase for convenience
Comment 3 Maksim Orlovich 2006-08-23 16:04:46 UTC
I have a feeling it may be my fault, and it's likely related to some of the other syncing bugs...
Comment 4 Maksim Orlovich 2007-06-08 22:10:57 UTC
Ugh. The troublemaker is the bizarre RenderTextArea::close call. I have no idea as to why it's there... Will annotate..
Comment 5 Maksim Orlovich 2007-06-08 22:50:47 UTC
.. And that call seems to be a workaround for some QTextEdit bug, which causes us to not set initial value right.. investigating
Comment 6 Olivier Vitrat 2007-06-21 17:06:14 UTC
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
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
Comment 8 Maksim Orlovich 2007-10-19 04:49:19 UTC
*** Bug 151017 has been marked as a duplicate of this bug. ***
Comment 9 Michael Daum 2008-01-08 13:44:29 UTC
Which release will have this bugfix? I still get the same error in kde-3.5.8.
Comment 10 Maksim Orlovich 2008-01-08 18:16:47 UTC
4.0.0