81865 - Bizarre problems with === on XULElement

Status: RESOLVED FIXED

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

Description

[Peter Wilson]

This is a weird one. 

I load a XUL document using DOMParser to use as a datamodel for a screen 
designer. 
I then maintain two views of the datamodel. A tree view and a form view, each 
with its own window and DOM document. 

To associate the view elements back to the datamodel I use two Objects (as a 
propertyMap) to map an view element attribute "XULAPP-ID" back
to the datamodel element. I store the XULAPP-ID attribute on every element in 
the view documents. (see attached diagram).

When a user clicks on a button (say) in the form view the following steps occur.

Form View:
1. the event.target is used to find the view button element and the the 
xulapp-id attribute is obtained.
2. Map2 is used to get a reference to the original DOM Model (button) element.
3. The button is marked as selected.
4. The DOM Model (button) element is passed as a parameter to a notification 
method on the tree view.

Tree View:
5. This callback method scans Map1 linearly looking for the entry with the same 
DOM Model element.
6. Compare map1 entry and parameter using === 
7. Once the map entry is found the treeitem can be located and shown as 
selected.

This fails at step 6. As far as "for in" can determine the objects are present 
and equal.


Now here's the weird bit. If when I load the dataModel (and before the other 
views are created)
I visit every element in the dataModel and do 
element.setAttribute("AnyoldValueXXXX","true"), then the === test starts working 
again. 
Note that AnyOldValue is completely arbirary - so long as it is not used 
anywhere else.

This is reproducible. If I comment out the 
setAttribute("AnyoldValueXXXX","true") the problem returns.

Somehow the original objects in the datamodel are defective - the setAttribute 
seems to fix them up in some way.


Note: this complicated scheme is only necessary as I unable to store direct 
references to the DOM Model from the view elements.
See bug 81452 which describes how Javascript properties of XPConnect objects are 
"lost" when items are added to a tree widget.

I may be doing something stupid - but I can't fathom how adding an unused 
attribute causes an === test to work / or not.

Comment 1

[Peter Wilson]

Attachment: Object diagram for bug 81865

Comment 2

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I'm assuming DOMParser is one of the xmlextras.  But this sounds more like a DOM
problem, although I'm not sure.  Assigning to jst, cc:vidur.

Comment 3

[Johnny Stenback (:jst)]

Without thinking about this too much it sounds like this could be related to the
problems we've had with event.target, this problem was fixed on friday
afternoon, could you please retest with a build from saturday or later?

Comment 4

[Peter Wilson]

Just downloaded 5-21. It dies in DOMParser.parseFromString - which stops my app 
before the reported problem. Unable to verify solution. Will try again in a 
couple of days.

Comment 5

[Johnny Stenback (:jst)]

Peter, is this still a problem?

Comment 6

[Peter Wilson]

Not this one - one of the daily downloads in early June seems to have fixed it.
(Somewhat accademic as I have been unable to parse any XUL documents for over a 
month due to other bugs.)