771926 - DOMUserData not copied during clone operation for element attributes

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, defect, P5)

Description

[giovanni]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0.1
Build ID: 20120614114901

Steps to reproduce:

The following script creates a div element and sets an attribute, then sets some user data using setUserData() on both the element node and the Attr node, using a copy handler.
Then i clone the element, the user data set on the element is correctly duplicated, while the user data in the attr is not. Sounds like a bug to me since I would definitely expect it to copy everything.

var d = document.createElement("div");
d.setAttribute("hello", "world");

var _copyHandler = {
  "handle": function(op, key, data, src, dst) {
    console.log("copying " + key);
    dst.setUserData(key, data, _copyHandler);
  }
};

d.setUserData("test1", "test1v", _copyHandler);
d.attributes[0].setUserData("test2", "test2v", _copyHandler);

var dd = d.cloneNode(true);
console.log(dd.getUserData("test1"));
console.log(dd.attributes[0].getUserData("test2"));



Actual results:

copying test1
test1v
null


Expected results:

copying test1
copying test2
test1v
test2v

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Whether or not this is a bug, this is probably WONTFIX.
userData has been removed from DOM4, and will be removed from Gecko at some point. (Bug 749981)

Comment 2

[giovanni]

so what is the right way to do it?
it came in really handy to solve my problem of enriching the DOM with some semantic information.

Comment 3

[giovanni]

either way i don't see why it shouldn't be fixed, DOM3 is the current standard and I don't see why it shouldn't be implemented in the right way...

Comment 4

[Alex Vincent [:WeirdAl]]

DOM4 is the standard Mozilla is trying to implement these days.  DOM3 is for all intents and purposes deprecated in their eyes.  It's also worth noting that DOM4 no longer supports attributes as nodes, so getUserData and setUserData would be going away for you anyway.

getUserData and setUserData were ideas that sounded good at the time, but really haven't caught on.  These days we have WeakMap and Map in JavaScript, which obsolete the needs for these.

Why do you need getUserData and setUserData?

Comment 5

[giovanni]

@Alex: I'm trying to implement a template engine purely DOM based, where I attach the semantic information directly to the DOM nodes, and I need this information to survive any further manipulation of the DOM that might happen by other scripts.
For example a list might be: <ul><li data-tpl="foreach varname">...</li></ul>, and my template engine would be duplicating this <li> node as many times as needed, but it has to attach the information to the created nodes that they have been generated and might need some cleaning up. setUserData() worked like a charm, do you think that I can use this WeakMap by simply giving the node object instance to it? How can I be 100% sure that the same exact node won't change it's hash code? And how can I capture node cloning to also copy the data in my WeakMap?

Anyway I realize this is offtopic here, can you point me to the right mailing list where we can discuss this issue? I really believe I'm on to a new generation of JS-level template engines. I even have a running prototype.

Comment 6

[Alex Vincent [:WeirdAl]]

(In reply to giovanni from comment #5)
> @Alex: I'm trying to implement a template engine purely DOM based, where I
> attach the semantic information directly to the DOM nodes, and I need this
> information to survive any further manipulation of the DOM that might happen
> by other scripts.

So you are looking for the UserDataHandlers that happen when a node is cloned.  In that direct case, with attributes, you're pretty much not going to get it from Mozilla.  (I don't work for them, by the way.)  You're going to have to get... creative.  Say, with attributes in a different namespace (assuming you'll allow yourself that) and setting a user data handler on the element (which won't work forever, either).

For what it's worth, even the official DOM specification URL points to a working draft of DOM4: http://www.w3.org/TR/dom/

> For example a list might be: <ul><li data-tpl="foreach
> varname">...</li></ul>, and my template engine would be duplicating this
> <li> node as many times as needed, but it has to attach the information to
> the created nodes that they have been generated and might need some cleaning
> up. setUserData() worked like a charm, do you think that I can use this
> WeakMap by simply giving the node object instance to it? How can I be 100%
> sure that the same exact node won't change it's hash code? And how can I
> capture node cloning to also copy the data in my WeakMap?

WeakMaps and Maps are true hashtables in JavaScript.  In a WeakMap, the key must be an object (functions are allowed, but primitives like numbers are not), and values can be anything.  In a Map, the key and value can be anything.  What I'd consider in your case is a two-dimensional hashtable:  the first dimension being a WeakMap keyed off the node, and the second dimension keyed off strings like the user data.  But this doesn't solve the notification problem of when a clone is happening... 

> Anyway I realize this is offtopic here, can you point me to the right
> mailing list where we can discuss this issue? I really believe I'm on to a
> new generation of JS-level template engines. I even have a running prototype.

I'm definitely interested in discussion, but I don't have much time.  I've been trying in my spare time to build my own templating system for years, eventually concluding very reluctantly that the native DOM would not support what I needed - and that I needed to write my own.  (I even bypassed projects like envjs.  I was not happy about that.)

Send an e-mail to my bugzilla e-mail address directly with details, or try a brief (!) message to the WHATWG mailing list.  I know a few people there might be interested.  If you're in the San Francisco Bay Area, I'd be happy to compare notes over a meal.

Comment 7

[Peter Van der Beken [:peterv]]

Regardless of deprecation status of UserData, this is pretty hard to implement (there's a comment about that in nsNodeUtils::CloneAndAdopt) so it would probably not happen soon.

Comment 8

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.