350850 - onload handler fires with DOM manipulation, but without reloading

Status: UNCONFIRMED

(Core :: DOM: Events, defect, P5)

Description

[Will Lewis]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060607 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060607 Firefox/1.5.0.4

Load an iframe, clone the node, append the old node and a clone to a new parent, and replace the original element.  The load handler fires twice on insert, even though nothing has changed with the original element.

Reproducible: Always

Steps to Reproduce:
Testcase will be attached

Comment 1

[Will Lewis]

Attachment: Testcase

Comment 2

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

Could you please attach a minimal testcase?
I don't know what I should do with the current testcase.

Comment 3

[Will Lewis]

Just click the split button.  The load alert should only display once.  The JS code being executed is as follows:

      function split(aElement) {
        var parent = aElement.parentNode;
        var splitter = document.createElementNS(kXULNS, "splitter");
        var grippy   = document.createElementNS(kXULNS, "grippy");
        var clone = aElement.cloneNode(true);
        var newbox = document.createElementNS(kXULNS, "box");
        newbox.setAttribute("flex", "1");
        splitter.appendChild(grippy);
        parent.replaceChild(newbox, aElement);
        newbox.appendChild(aElement);
        newbox.appendChild(splitter);
        newbox.appendChild(clone);
      }

aElement is never being reinstantiated, it is never being modified, it is never being reloaded.  Why is the onload handler fired again?

Comment 4

[Xavier]

I think this is related :
I have noticed that the programatically added elements to a Node that was created from a XBL binding are not cloned, and that when you appendChild or insertBefore such a clone the constructor of the XBL(s) are called...
I'm not sure wether this is a bug or a feature, though. But it's a pain in ... somewhere.

Comment 5

[Will Lewis]

The other really troublesome thing about this bug is that all JavaScript state for the original element is lost.  So anything that happened dynamically in the original is lost when the element is cloned and reparented.

Comment 6

[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.