319316 - replaceChild node gets corrupted

Status: RESOLVED WORKSFORME

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

Description

[Csaba Gabor]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051024 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051024 Firefox/1.6a1

When I transfer a table in an IFrame to replace a subtable in the main page, the user defined properties of the newly transferred table are lost SUBSEQUENTLY to being set onto the transferred table.  This always happens after keyboard navigation, but that is not the only criterion.  Forms are not involved.

The way it works is that clicking on a link causes a table to be loaded into an iframe.  Well, the table is part of an html document that contains an onload.  The onload identifies the subtable in the main page and replaces it with the table loaded into the iframe (using .replaceChild()).  Prior to doing this, it saves away some user defined properties of the new table, and once the replaceChild has been done, these properties are written to the new node.  An alert is then shown (after a 1 second delay, to allow settling) to determine what the properties in question are.

Reproducible: Sometimes

Steps to Reproduce:
1.  Refresh the page once by doing F5 (dismiss any alert with space).
    Then Alt+d, Return
2.  Click on the 'Swap in table' link.  Move the mouse over the
    'Test Properties' button right away, while waiting for the alert
    box to come up.
3.  Press space to dismiss the alert box.
4.  Now click on the 'Test Properties' button.
5.  Dismiss the alert box with the mouse
6.  Now press Shift+tab to refocus on the link.
7.  Now click the 'Test Properties' button again.
Actual Results:  
By the third, and often 2nd, alert the properties that had been set are undefined.  The demo is finicky, and it frequently happens that the properties become undefined by the second click instead of the third.  Rarely, they are already undefined by the first alert.



Expected Results:  
I expect not only the table to get transferred, but all its properties/attributes as well (including user defined ones).  But even if (as with .cloneNode(...)) certain things are not transferred, I still expect that if I set properties/values explicitly on the new node (post transferrence) that they will stay there.

Csaba Gabor from Vienna

This bug is finicky and sometimes the values want to revert to undefined immediately.

Comment 1

[Csaba Gabor]

Attachment: the replacement table

This file is invoked by the main test file and targetet toward the named IFrame in its page.  Once there, it makes a copy of the properties of the included table, transfers (by means of replaceChild) the table to its containing page, and then transfers the saved properties.

Comment 2

[Csaba Gabor]

Attachment: Main test page

Use this page to test the reported problem.  The alert that you get will show you what the .id, .prop1, and .prop2 are for the subtable at row 2, cell 0 of the main table on this page.

Comment 3

[Alex Vincent [:WeirdAl]]

WFM Firefox 1.5.0.4

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

Comment 4

[Alex Vincent [:WeirdAl]]

Also WFM on SeaMonkey trunk:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060614 SeaMonkey/1.5a

Comment 5

[Csaba Gabor]

Fabulous!  WFM too on FF 1.5.0.4
Evidently, somebody done gone and fixed this bug without being aware of this report.  Anyway, I suppose I should mark it as fixed if there is no objection (or inform me if there is an alternate procedure to be followed).

There is one funny thing going on with the example, but I'll file a separate bug on that:
Bring up the Main test page.
Click on the link.
Click on the alert.
Click on the button.
Press the spacebar to dismiss the alert.

Now notice that the caret (I have caret browsing mode turned on) is on the leftmost side of the link, though the focus rectangle correctly shows on the button.  If at this point I do a shift tab, then the body is selected (or something like that) rather than focus going to the link - that is to say, the tab order has become messed up.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Works fine, but we don't know what fixed it, so WORSKFORME.