Open Bug 229703 Opened 20 years ago Updated 1 year ago
I seem xbl is destroyed when I call remove
Child and then append Child
Type text into textfields and press button. Text typed into textbox will disapear. Text typed into html:input will copied.
When you take a node out of the DOM, its presentation, including any XBL binding WILL be destroyed. That's correct. If state stored in that presentation needs to be preserved, the presentation needs to take care of that. The layout object for <html:input> does so. In other words, the destructor for the textbox binding needs to save the value on the node itself and the constructor needs to restore it as needed. Not a DOM bug; over to XP Toolkit.
Assignee: general → jag
Status: UNCONFIRMED → NEW
Component: DOM: Core → XP Toolkit/Widgets
Ever confirmed: true
QA Contact: ian → jrgmorrison
<textbox> already has some code which looks as if it's trying to save/restore the value using boxObject.[sg]etProperty - if that's wrong, where could the value be saved?
No, that looks right... What's the value of this.inputField.value in that destructor? What string comes out of the boxObject in the constructor? Is the problem that the "value" inheritance is applied after the constructor fires or something?
A quick dump in the JS console shows that the textbox, having moved, now has a new box object, so that all the old properties have been lost...
Ah, indeed. When nodes are removed from a document they wipe out their box object (see nsXULElement::SetDocument and nsGenericElement::SetDocument). So storing state on the box object really doesn't work for nodes moving out of the DOM then back in. It works fine for nodes going to display:none and back. jst, should we leave box objects around until the nodes are destroyed, maybe? It may make sense to clear the box object when: 1) The node is destroyed 2) The node is inserted into a new document (such that a new nodeinfo is needed) in both cases, we would use the document in the old nodeinfo as the document in which the box object lives...
Alexander, what object are you talking about exactly? The DOM node is NOT being destroyed at any point here. What is being destroyed is the node's presentation (rendering objects), which DO need to be destroyed as soon as the node is removed from the DOM (otherwise it would continue to render).
Ok. I agree presentation object should be destroyed. But I can't understand why should I be care for saving properties by boxObject as in the case of textbox? And I have a question: Is boxObject DOM object, presentation (rendering object) or something else? And why boxObject is destroyed when I remove element from DOM if boxObject serves to save propeties.
> But I can't understand why should I be care for saving properties by boxObject > as in the case of textbox? _You_ probably shouldn't. The binding author should. And I'm not sure the box object is the right place to save it, truth to tell. I would have saved it on the node... > And I have a question: Is box object DOM object, presentation (rendering > object) or something else? Almost all methods and properties on nsIBoxObject are presentation-dependent, so I would say it's a presentation object... But it's treated as a something else for some unknown-to-me reasons. > And why boxObject is destroyed when I remove element from DOM > if boxObject serves to save propeties. Because whoever wrote the binding code clearly wasn't talking to whoever wrote the boxobject code.... I suspect they only tested using display:none, not actually removing nodes from the DOM.
> Then why do xbl's properties belong to presentation object but not to DOM > object? Because XBL is a form of presentation -- the same DOM node could have different XBL bindings bound to it in different parts of the DOM tree, for example.... just like CSS presentation. I'm not sure what your last question is asking... the presentation object for html:input makes sure to stash the value away on the DOM node when it's destroyed so that the value survives destruction of presentation objects (eg so that display:none forms can submit). The textbox binding tries to save the state as well, but saves in a less permanent place than the DOM node, hence the issues described in this bug. The more I think about it, the more I think textbox needs to be storing properties on the domnode itself, not on the boxobject.
Neil, if you have thoughts (even a clear explanation of what the lifetime of boxobjects should be), please let me know.... (and document that in the IDL?)
This problem cropped up with rdfliners... what used to happen was that when an rdfliner was made visible its box object would create a selection object (which holds a weak reference to the box object) and attach it to the treebuilder object; if you then removed and readded the node you would delete the box object thus invalidating the pointer in the selection object... Any custom view is also set as a property on the box object, so that removing and readding a tree will forget the custom view... I don't like the idea of setting attributes on the DOM node so where else can you suggest?
> I don't like the idea of setting attributes on the DOM node Why not? You read any existing "value" attribute and use it as the initial value anyway, no? As for what else I can suggest, it's to make box objects a little more persistent as per comment 6. Note that state would still get lost if you moved a node between documents, then... (boxobjects are very much per-document).
The value is stored on the box object so that it will survive a dynamic theme change (not that we support that any more...) - it could have been stored as an attribute but it wasn't and I'm guessing there was a reason for that...
Ah, I see. In other words, the goal is NOT to handle the situation at hand, huh? ;) Well, if the solution from comment 6 is desired at some point let me know.
To comment <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=229703#c10">10</a>. I think xbl author shouldn't to care for saving of properties when I set up property display:none or move element to other place in DOM. Because it give discomofort due development of xbl. I think it will be more comfortable If I will not take care of properties saving and if it will be done automatically. More. I don't understand how work saving of properties of textbox (comment <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=229703#c3">6</a>). Because xbl destructor isn't called at all (see testcase of bug <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=230086">230086</a>).
You need to log in before you can comment on or make changes to this bug.