Closed Bug 86372 Opened 23 years ago Closed 19 years ago

Problems when changing the text inside a TEXTAREA using DOM-1

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Platform:
x86
Other
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.0.1

People

(Reporter: Erich.Iseli, Assigned: john)

References

Details

(Keywords: dom1, testcase)

Attachments

(2 files)

Same as Comment #1
1.23 KB, text/html
Details
Revised Testcase
1.24 KB, text/html
Details 
Basically, the problem is that the DOM-0 (forms[0].elements[0].value) does not
see the same thing like the DOM-1 (document.getElementsByTagName
("textarea").items(0).childNodes.item(0).nodeValue).

While the DOM-0 can see the text that is in the source code, and can also see 
the text written by the user, it cannot see text added by a DOM-1 procedure.

While the DOM-1 can add text to the tree and see it, it doesn't see text 
written by the user.

This different interpretation leads to the following situation:

- if you type in some text and afterwards add another text using the DOM-1, 
both texts are overlapping. Same if you first add using DOM-1 and then type in
some text.

- if you have no text written and add some using DOM-1 ,you cannot select it.
it is virtually inexistent. You can only see the text displayed, but it's not
there for normal use.
Sorry to post the code here, but I cannot upload an attachment, because I'm 
behind a firewall.
---------------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
  <title>addNode testcase</title>
</head>
<script type="text/javascript">
var myTA, myTN;
function addNode() {
  input = prompt("Enter some text to be added","Hello World");
  myTN = document.createTextNode(input);
  myTA = document.getElementsByTagName("textarea").item(0);
  myTA.appendChild(myTN);
  myTA.normalize(); // Try removing this and appending several text nodes...
}
function info() {
  myTA = document.getElementsByTagName("textarea").item(0);
  alert("The DOM-1 sees the following inside the TEXTAREA: "+viewChildren
(myTA));
  alert("The DOM-0 sees the following inside the TEXTAREA: "+document.forms
[0].elements[0].value);
}
function viewChildren(myEl) {
  eCh = myEl.childNodes;
  temp = "";
  for (i = 0; i < eCh.length; i++) {
    temp = temp + eCh.item(i).nodeValue+"\n";
  }
  return temp;
}
</script>
<body>
<form action="" method="get">
<textarea name="text" rows="5" cols="75"></textarea>
</form>
<p>
<input type="button" value="appendChild (into TEXTAREA)" onclick="addNode
()"><br>
<input type="button" value="What is inside now?" onclick="info()"><br>
<input type="submit" name="button" value="Submit Form">
</p>
</body>
</html>
Keywords: dom1, testcase
Also note that if you don't use normalize() after having added several text 
nodes, every text node gets printed on the top of all others.
I think this is caused by bug 17003, which is being worked on.
To answer at least one of your questions, text that is typed into a textarea is
*only*, and *should only* be available by using textarea.value, the content of
the textarea should be the default value of the textarea, and this will *not*
change when the user writes into the textarea. Also, changing the content of a
textarea (i.e. it's child nodes) should *not* affect what's displayed on the
screen if the user has typed in the textarea.

AFAICT the only problem here is that the content of a textarea element (i.e.
it's child nodes) are visible ontop of the textare itself.
Ok, I see your point, Johnny. But i don't see why an added textnode should not
be shown. While I like to stick to standards, I hate it to see we are always
interpreting them differently than the other browser (read IE). Often, when I do
some javascript programming, I'm doing it *intuitively*, reading some reference
and most of the time, it works like I want in IE. In Moz, there's always some
dark explanation why this should not work like this. If there is no explanation
in the specs on how to display added text nodes, then we definitely should do it.
The DOM spec is very clear about this issue. IE is broken wrt this.
Targetting for mozilla1.0
Target Milestone: --- → mozilla1.0
What about the defaultValue property?

The defaultValue is suppose to reflect the contents of the textarea.
So if you add a textNode,the defaultValue should change as well.
Then,because the defaultValue changed,the contents of the control should be 
reset.


You could then use the textNode methods and properties to modify the 
defaultValue.


Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Ricky, could you re-test this please? It should work now, with the fix for bug
17003. Thanks in advance.
Attached file Same as Comment #1 — 

    
    

    
  
Fabian, this is still not fixed in my 2002-01-31 Win98 build. To reproduce, load
the testcase and type
"xxxxxxxxxxx" inside the textarea
Then click the button "Append Child" and leave the "Hello World" text as is.
Result:
the xxxxxxxxxxx and the Hello World are written on the top of each other

Now if you click the button "What's inside now" you get "DOM-1 sees 'Hello
World" and "DOM-0 sees 'xxxxxxxxxxx'"

So: not fixed

    
    

    
  
jkesier, would you look at this one, or should this go to rods?
Assignee: jst → jkeiser

    
    

    
  

      
      
      
      

        Attached file
          
        Revised Testcase
        — 
      

    


  
This testcase uses .defaultValue instead of .value.

    
    

    
  
Modifying the textarea's value does *not* change the underlying text node, and
should not.  It only changes the value.  .defaultValue and .value are two
different entities entirely.  .defaultValue is the one that reflects the text
node(s).  So the original problem in the bug is in fact fixed (verify with this
testcase).

There are display problems though.

sicking, have you any idea wassup with the display?  Did you see that at all
during your textarea changes?

    
    

    
  
Oops.  sicking, please see previous comment.

    
    

    
  
Ok. Changing the content of the Textarea does not change the underlying text node.

But then, consider the following situation:

you load a page with a default value of "Hello World", you type in ", good to
see you", you should be able to see "Hello World, good to see you". If you add
at this point another text node to the default value, for example "-----------",
these dashes should NOT display, since the default value has already changed,
right? Or should it insert between the end of the default value and the typed in
value?

Then I also wonder what the meaning of changing the default value is, in case it
has already been changed.

    
    

    
  
Yep, I agree compleatly with your "Hello World, good to see you"? And if you 
only use the DOM then that is the result you get since the fix of bug 17003 a 
few weeks ago.

However, for some reason all textnodes except the first below a textarea is 
shown *on top of* the textarea. However the textarea is only affected 
visually, .value and .defaultValue behaves exactly as you describe.

So this is a layout bug: Children below a textarea should not be show. 
Currently only the first textnode is hidden, all other are displayed
Component: DOM HTML → Layout

    
    

    
  
Here's the general rule we use in Mozilla: The defaultValue is copied to the
value *as long as the value has not been changed.*  As soon as the value is
changed, defaultValue no longer affects it.  This is our way of implementing the
spec, which says changing defaultValue should not affect value, and also giving
something like what users expect, preserving compatibility.

kin, does this look familiar to you?  Does this display problem belong with
editor?  (Type something, then hit Append Child.)

    
    

    
  
Sounds to me that this is a bug in nsCSSFrameConstructor and this should be
pretty easy to fix. The frame constructor should *never ever* even look at
children of a textarea, if we'd fix that, the frames would never be created and
life would be better.

    
    

    
  
Yeah, I agree with jst. Something supresses frame creation for these Textarea
child nodes when the doc is loaded and parsed, so we need to do the same thing
during the content inserted notification. Here's a partial stack of how the text
frame for the inserted node is created:
 

nsTextFrame::nsTextFrame() line 1281
NS_NewTextFrame(nsIPresShell * 0x05095698, nsIFrame * * 0x0012cbf4) line 1257 +
31 bytes
nsCSSFrameConstructor::ConstructTextFrame(nsIPresShell * 0x05095698,
nsIPresContext * 0x051d5cf8, nsFrameConstructorState & {...}, nsIContent *
0x049cae10, nsIFrame * 0x04b9d918, nsIStyleContext * 0x05170bc4, nsFrameItems &
{...}) line 4304 + 13 bytes
nsCSSFrameConstructor::ConstructFrameInternal(nsIPresShell * 0x05095698,
nsIPresContext * 0x051d5cf8, nsFrameConstructorState & {...}, nsIContent *
0x049cae10, nsIFrame * 0x04b9d918, nsIAtom * 0x015562b8, int 0, nsIStyleContext
* 0x05170bc4, nsFrameItems & {...}, int 0) line 7001 + 41 bytes
nsCSSFrameConstructor::ConstructFrame(nsIPresShell * 0x05095698, nsIPresContext
* 0x051d5cf8, nsFrameConstructorState & {...}, nsIContent * 0x049cae10, nsIFrame
* 0x04b9d918, nsFrameItems & {...}) line 6916 + 56 bytes
nsCSSFrameConstructor::ContentInserted(nsCSSFrameConstructor * const 0x04d01d58,
nsIPresContext * 0x051d5cf8, nsIContent * 0x04acbf10, nsIContent * 0x049cae10,
int 1, nsILayoutHistoryState * 0x00000000, int 0) line 8763
StyleSetImpl::ContentInserted(StyleSetImpl * const 0x04d01cd0, nsIPresContext *
0x051d5cf8, nsIContent * 0x04acbf10, nsIContent * 0x049cae10, int 1) line 1446
PresShell::ContentInserted(PresShell * const 0x050956a0, nsIDocument *
0x04dd5698, nsIContent * 0x04acbf10, nsIContent * 0x049cae10, int 1) line 5155 +
53 bytes
nsDocument::ContentInserted(nsDocument * const 0x04dd5698, nsIContent *
0x04acbf10, nsIContent * 0x049cae10, int 1) line 1889
nsHTMLDocument::ContentInserted(nsHTMLDocument * const 0x04dd5698, nsIContent *
0x04acbf10, nsIContent * 0x049cae10, int 1) line 1355
nsGenericHTMLContainerElement::InsertChildAt(nsGenericHTMLContainerElement *
const 0x04acbf10, nsIContent * 0x049cae10, int 1, int 1, int 1) line 3804
nsHTMLTextAreaElement::InsertChildAt(nsHTMLTextAreaElement * const 0x04acbf10,
nsIContent * 0x049cae10, int 1, int 1, int 1) line 572 + 25 bytes
nsGenericElement::doInsertBefore(nsIDOMNode * 0x049cae2c, nsIDOMNode *
0x00000000, nsIDOMNode * * 0x0012d608) line 2290 + 35 bytes
nsGenericHTMLContainerElement::AppendChild(nsGenericHTMLContainerElement * const
0x04acbf10, nsIDOMNode * 0x049cae2c, nsIDOMNode * * 0x0012d608) line 556
nsHTMLTextAreaElement::AppendChild(nsHTMLTextAreaElement * const 0x04acbf40,
nsIDOMNode * 0x049cae2c, nsIDOMNode * * 0x0012d608) line 92 + 23 bytes
XPTC_InvokeByIndex(nsISupports * 0x04acbf40, unsigned int 18, unsigned int 2,
nsXPTCVariant * 0x0012d5f8) line 106
XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNative::CallMode
CALL_METHOD) line 1998 + 42 bytes
XPC_WN_CallMethod(JSContext * 0x0380f5b8, JSObject * 0x0499b408, unsigned int 1,
long * 0x051404e4, long * 0x0012d8d4) line 1266 + 14 bytes

I don't think this is an editor issue, since this is all happening outside the
editor.

    
    

    
  
To avoid confusion,it should be noted that the behavior of defaultValue has
been changed.
In DOM 1,setting defaultValue would change the value,but in DOM 2,it no
longer does.

    
    

    
  
changed priority to P3
Priority: -- → P3

    
    

    
  
So.. in nsHTMLContentSink, we never create text nodes to go under the textarea.
 We just call SetDefaultValue on it with all the text.  Then the textarea
creates the text node and inserts it....

I'm not sure why no frame construction happens here, though -- textarea is not
blocking construction of child frames....

    
    

    
  
retargeting
Target Milestone: mozilla1.0.1 → Future
Target Milestone: Future → mozilla1.0.1
Depends on: 152329

    
    

    
  
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050614
Firefox/1.0+ ID:2005061421

I've tested the Revised Testcase again (after a few of the textarea bugs were
fixed).

Appending text once "test1", clicking the "What's inside" shows the contents
correctly in both DOM-1 and DOM-0. 

Appending the text "test2", and the alerts show what's inside for DOM-0 and
DOM-1 properly, BUT the textarea itself only shows "test1".

Appending the text "test3", the alerts once again show the contents properly,
but now the text area shows "test1test2" but "test3" is not visible.

    
    

    
  
Blake, did you fix this too, with bug 152329?

    
    

    
  
Yeah, I can no longer reproduce this. Marking as FIXED.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: