Closed
Bug 37163
Opened 25 years ago
Closed 23 years ago
Text Widgets lose their values when removed/inserted
Categories
(Core :: DOM: Core & HTML, defect, P3)
Core
DOM: Core & HTML
Tracking
()
VERIFIED
FIXED
Future
People
(Reporter: rsalesas, Assigned: rods)
References
Details
(Keywords: dom1, Whiteboard: [nsbeta3-])
Attachments
(1 file)
|
(deleted),
text/html
|
Details |
The following is a bit complicated, but basically it fails in that it deletes
the information within the input field once the items are "swapped". This works
fine in Internet Explorer, and unless I'm missing something, it should be
possible to re-order nodes without losing their values.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>Untitled</title>
</head>
<SCRIPT>
function addNodes(){
var objParent = document.getElementById("surveySheet");
var questionNode = document.createElement("LI");
questionNode.id = "q1";
objParent.appendChild(questionNode);
// add a question title node
var questionTextNode = document.createElement("INPUT");
questionTextNode.type = "text";
questionNode.appendChild(questionTextNode);
var questionNode1 = document.createElement("LI");
questionNode1.id = "q2";
objParent.appendChild(questionNode1);
// add a question title node
var questionTextNode1 = document.createElement("INPUT");
questionTextNode1.type = "text";
questionNode1.appendChild(questionTextNode1);
document.surveyModify.create.disabled = true;
}
function swapNodes(){
obj1 = document.getElementById("q1");
obj2 = document.getElementById("q2");
exchangeNode(obj2, obj1);
}
function exchangeNode(swappedNode, node){
parentNode = swappedNode.parentNode;
parentNode.removeChild(swappedNode);
parentNode.insertBefore(swappedNode, node);
}
</script>
<body>
<form name = "surveyModify">
<ol id=surveySheet>
</ol>
<input type="button" name = "create" onclick="addNodes()" value="Create Nodes">
<input type="button" name = "swap" onclick="swapNodes()" value="swap">
</form>
</body>
</html>
|
||
Comment 1•25 years ago
|
||
updating component. I know this probably isn't right but I didn't know where
else to go with this one.
Assignee: asadotzler → rogerl
Component: Browser-General → Javascript Engine
QA Contact: jelwell → pschwartau
|
||
Comment 2•25 years ago
|
||
Don't know enough about DOM to say if this is correct or not, but the JS engine
side of it is running just fine as afar as I can see.
Assignee: rogerl → jst
Status: UNCONFIRMED → NEW
Component: Javascript Engine → DOM Level 0
Ever confirmed: true
QA Contact: pschwartau → desale
Well, somewhere, on some side, something is dropping the data. At the start
there is a value in the field, and at the end it is no longer there. The item
that is not removed works fine. The item that is removed loses its data.
Furthermore, if you do not do "removeChild", and only do "insertBefore", the
same thing happens (just in case anyone thinks that removing and losing
is "ok"). Again, this makes dynamic interfaces a little impossible.
|
||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → M17
|
|
||
Comment 4•24 years ago
|
||
This bug has been marked "future" because the original netscape engineer
workingon this is over-burdened. If you feel this is an error, that you or
another known resource will be working on this bug,or if it blocks your work in
some way -- please attach your concern to the bug for reconsideration.
Target Milestone: M17 → Future
This bug results in data loss. I find it hard to believe that this is
acceptable behaviour in any release. Should such bugs not be given priority? If
you are doing any kind of dynamic pages, a requirement of a web application,
this bug will bite.
|
||
Comment 6•24 years ago
|
||
I feel this is kinda important because it is resulting in data loss.
Nominating for nsbeta3.
Johnney I leave final decision upto you. You could judge this one better.
Keywords: nsbeta3
|
||
Comment 7•24 years ago
|
||
Changing component from DOM0 to DOM1. Marking helpwanted. Data loss in DOM
usage is indeed a serious issue. Tom, Vidur, any chance you could lend a hand
with this one? Someone else?
Component: DOM Level 0 → DOM Level 1
Keywords: helpwanted
|
|
||
Comment 8•24 years ago
|
||
Rods agreed to look into this, reassigning. Thanks Rods!
Assignee: jst → rods
Status: ASSIGNED → NEW
Keywords: correctness
OS: Windows 2000 → All
Hardware: PC → All
Target Milestone: Future → ---
|
Assignee | |
Comment 9•24 years ago
|
||
I think this is a dup. I have researched this issue before.
Status: NEW → ASSIGNED
|
|
Assignee | |
Comment 10•24 years ago
|
||
|
|
Assignee | |
Comment 11•24 years ago
|
||
I was wrong this isn't a dup, this is a different issue.
Changing summary to text node lose the contents
I think the issue here is when the text node gets set with a null document and
then later gets set with a "new" document (which is actually the same as the old
document) I think the editor gets confused.
To run the example:
1) Set the text using script or type into the text field
2) Press "Remove" to remove the node
3) Press "Add" to insert the node back in
When it is inserrted back in, it loses its value that was set via script or
typed in.
reassigning to editor group
Assignee: rods → beppe
Status: ASSIGNED → NEW
Keywords: helpwanted
Summary: Nodes lose their values when removed/inserted → Text Nodes lose their values when removed/inserted
|
||
Comment 12•24 years ago
|
||
handing this over akkana for review/debug and including kin
setting this to NEED INFO until we understand the scope of the issue
Assignee: beppe → akkana
Whiteboard: [NEED INFO]
|
||
Comment 13•24 years ago
|
||
This happens because the editor and it's current value (anonymous content) are
associated with the Text Control's frame. When you remove the node from the DOM
tree ... the text control's frame, anonymous content, and editor are destroyed
causing us to lose any user modified data.
I believe mjudge@netscape.com has a bug on his plate that is very similar to
this ... having to do with the fact that we lose values the address text widgets
in the mail compose window if the address window/toolbar is collapsed and then
uncollapsed.
We should probably update the value on the Text Control's node when the frame
goes away, so that we can restore the value ... but the last I heard from
mjudge, there were problems doing that when the frame was going away.
Assignee: akkana → mjudge
Summary: Text Nodes lose their values when removed/inserted → Text Widgets lose their values when removed/inserted
Whiteboard: [NEED INFO]
|
||
Comment 15•24 years ago
|
||
i will look at this. the bug from the mailnews is not from being removed and
re-added. the dom elements were being destroyed then recreated. the html value
element should be being modified with the new data. I will check this out.
Status: NEW → ASSIGNED
|
|
Assignee | |
Comment 16•24 years ago
|
||
This sounds just like a bug kin has, check with him to make sure.
|
|
||
Comment 17•24 years ago
|
||
moving to m19, higher priority bugs need to be addressed for b3
Whiteboard: [nsbeta3+] → [nsbeta3-]
Target Milestone: M18 → M19
|
|
||
Comment 19•24 years ago
|
||
Nominating for nsbeta1, since nsbeta2,3, dogfood, rtm keywords are going to be
cleared soon and important bugs could loose attention. I think this one deserves
nsbeta1 nomination.
|
|
||
Comment 20•24 years ago
|
||
*** Bug 67364 has been marked as a duplicate of this bug. ***
|
|
||
Comment 21•24 years ago
|
||
Rods, I looked at this some more and I don't think this is a editor bug,
shouldn't the frame code use the nsIPresState to store the current state when
the text frame goes away? Modifying the HTML element to contain the new value
when the frame is destroyed is not the right solution for this problem.
Back to you, Rods.
Assignee: mjudge → rods
Status: ASSIGNED → NEW
|
||
Comment 22•24 years ago
|
||
jst: Why should the element not be holding on to the data?
|
|
||
Comment 23•24 years ago
|
||
The element should indirectly be holding on to the data but because the current
form control state is purely presentation state, there is no corresponding
attribute in the DOM that can be used for the state. The attribute 'value'
contains the default/initial value, not the current value, presentation state
does not belong in the DOM.
|
|
||
Updated•24 years ago
|
Component: DOM Level 1 → DOM HTML
|
|
Assignee | |
Comment 24•24 years ago
|
||
I am concerned about the the PresState holding the value because the control may
never be added back in again. So if a page had several fields that had their
value changed and then they went away, the PresState would then contain a bunch
of "orphaned" data.
But since this may happen to infrequent, maybe it is the best we can do.
Status: NEW → ASSIGNED
|
||
Comment 26•23 years ago
|
||
Just throwing in my 2cents worth...I've been able to create the same issue with
any element (well, at least the couple I tried), not just the text element.
I ran across this by creating a widget that uses a deck, and will reorganize
the deck by moving it's children around. The children may be any element, a
browser, textbox, etc. They revert to their original state when moved. The
basic steps are:
create an element
modify it's attributes
insert into document
modify element (type data into textbox, change page browser is looking at,etc.)
move (using insertBefore) to a different location in the document
element reverts to what it was prior to being inserted into the document.
|
||
Comment 27•23 years ago
|
||
Any chance of moving this forward? It's the critical one for cross-browser
DOM/DHTML-based content management applications. Mozilla would be a convenient
way to extend access to flexible forms-based interfaces to pltaforms other than
Windows. It should be part of Moz 1.0.
Unless there's a simple workaround like w. bug 102860...
r. vva
|
|
||
Comment 28•23 years ago
|
||
There's changes coming down the road already that should fix this. See bug 34297.
|
||
Comment 29•23 years ago
|
||
Fixed with bug 34297 landing.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Component: DOM: HTML → DOM: Core & HTML
QA Contact: stummala → general
You need to log in
before you can comment on or make changes to this bug.
Description
•