305065 - invalid behaviour of getAnonymousNodes() and getAnonymousElementByAttribute()

Status: RESOLVED WONTFIX

(Core :: XBL, defect)

Description

[alexander :surkov (:asurkov)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; ru-RU; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 (ax)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; ru-RU; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 (ax)

I have a binding with content:

<children includes="caption">
	<xul:description value="Binding" anonid="desc"/>
</children>
<children/>

I have a bound element:

<testbox>
	<button label="helo"/>
</testbox>

When I call in constructor the following methods, I get: 

document.getAnonymousNodes(this)[0] returns button element
document.getAnonymousElementByAttribute(this, 'anonid', 'desc') returns null

I expect to get description element.

Reproducible: Always

Comment 1

[Frederic Bezies]

*** Bug 305066 has been marked as a duplicate of this bug. ***

Comment 2

[Boris Zbarsky [:bzbarsky]]

I believe this is the right behavior.  Those methods get whatever is the current
DOM "inside" the binding, after all <children/> directives have been processed.
 Which means the <button> is there, and that <xul:description> is not.

Comment 3

[Martijn Wargers (dead)]

You mean instead of "after all <children/> directives have been processed",
"before the <children/> directives have been processed", otherwise I don't
understand it.

I think it is strange that document.getAnonymousNodes(this)[0] returns button
element, because the button element isn't anonymous. Shouldn't
document.getAnonymousNodes only return anonymous nodes?

Comment 4

[Boris Zbarsky [:bzbarsky]]

> Shouldn't document.getAnonymousNodes only return anonymous nodes?

No.  It should return whatever nodes are part of the binding's content model,
effectively.  That includes both nodes that are actually anonymous and nodes
that are inserted via children.

If the naming bothers you, talk to hyatt.  ;)

Comment 5

[alexander :surkov (:asurkov)]

(In reply to comment #2)
>  Which means the <button> is there, and that <xul:description> is not.

Since <caption> element is not presented as child of bound element then
<description> is presented as anonymous node. I think it means
getAnonymousNodes() and getAnonymousElementByAttribute() should return
<description> element.

Comment 6

[Martijn Wargers (dead)]

The anonymous content isn't inserted just yet, when the constructor is called
(if I understand it correctly), so <xul:description> isn't there yet.

But afterwards, it should be there, I guess, since this:
<children includes="caption">
	<xul:description value="Binding" anonid="desc"/>
</children>
means (afaik from an IRC chat): include the caption elements here, but if there
are no caption elements, then include the <xul:description>

Is there a document that clearly describes these sort of things, what should be
done (and what Mozilla is doing/not doing)?

Comment 7

[alexander :surkov (:asurkov)]

(In reply to comment #6)
> The anonymous content isn't inserted just yet, when the constructor is called
> (if I understand it correctly), so <xul:description> isn't there yet.

It looks strange. Why is constructor called if content of binding is not builded?

Comment 8

[Boris Zbarsky [:bzbarsky]]

Oh, I see.  I misunderstood the original code paste.  Can someone attach an
actual testcase I could work with to this bug, please?

Comment 9

[alexander :surkov (:asurkov)]

Attachment: binding

Comment 10

[alexander :surkov (:asurkov)]

Attachment: testcase

Comment 11

[Martijn Wargers (dead)]

Attachment: Testcase2

This is the same testcase, but now the xbl binding embedded in the testcase.
I see also these issues:
- the button with label="hello" should not be seen
- you should be able to see the xul:description with text 'You should see this
in the document'

Comment 12

[Boris Zbarsky [:bzbarsky]]

Actually, I think this is invalid -- there must be a <children> for every child node in Mozilla XBL1; if some child node doesn't match any <children> element, we just stick it in a random <children>.  Adding:

        <xul:hbox style="display: none"><children/></xul:hbox>

after the </children> in the testcases in this bug makes them work just fine.

Comment 13

[alexander :surkov (:asurkov)]

(In reply to comment #12)
> Actually, I think this is invalid -- there must be a <children> for every child
> node in Mozilla XBL1; if some child node doesn't match any <children> element,
> we just stick it in a random <children>.  Adding:
> 
>         <xul:hbox style="display: none"><children/></xul:hbox>
> 
> after the </children> in the testcases in this bug makes them work just fine.
> 

But anyway getAnonymousElementByAttribute() returns null. I guess since no <caption> elements are used then <description> should be inserted. But it isn't.

Comment 14

[Boris Zbarsky [:bzbarsky]]

> But anyway getAnonymousElementByAttribute() returns null.

Not if I add that other <children>...

Comment 15

[alexander :surkov (:asurkov)]

(In reply to comment #14)
> > But anyway getAnonymousElementByAttribute() returns null.
> 
> Not if I add that other <children>...
> 

I cannot find nothing per spec about what behaviour should be presented. If it shouldn't then invalid. If behaviour isn't defined then worksforme. Actually the present behaviour looks strage for me but practically I needn't in it.

Comment 16

[[e-mail]]

Please note that XBL1 and XBL2 behave differently when child node(s) exist that do not match any children element.

In XBL1, the binding is assumed to have an outer <children/> element that wraps the entire content. i.e. your binding is interpreted as <children><description/></children>.

In XBL2, the child node(s) are ignored and do not display. This can be emulated in XBL1 using <spacer hidden="true"><children/></spacer> (or bz's more long-winded but equivalent construction). So this bug will be fixed by XBL2.

Comment 17

[Boris Zbarsky [:bzbarsky]]

XBL is now disabled in Firefox (Bug 1583314) and is in the process of being removed from Gecko (Bug 1566221), so closing bugs requesting changes to its implementation as wontfix.