Closed Bug 86372 Opened 25 years ago Closed 21 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: 21 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: