XBL binding constructor/attachment

["neil.stansbury () redbacksystems ! com"]

Hi all,

I know about this document: https://developer.mozilla.org/en/XBL/XBL_1.0_Reference/Binding_Attachment_and_Detachment

But could someone clarify the circumstance under which an XBL binding is formally attached?

Given:

<elem id="abc" hidden="true"/>

var abc = document.getElementById( "abc" );
var xyz = document.createElementNS( MOZILLA_XUL_NS, "xul:xyz" );
abc.appendChild( xyz );

xyz.boundProperty = "123" // Warning 'undefined'
xyz.boundMethod( "123" ); // Error 'is not a function'

Both subsequent calls result in property "undefined" or "is not a function" warnings/errors. This also applies to the CSS display: none;

However, If the "hidden" attribute on the parent element is set via setAttribute() then the binding attachment works as expected.

thus:

abc.setAttribute( "hidden", "true" );
abc.appendChild( xyz );

xyz.boundProperty = "123" // Works as expected
xyz.boundMethod( "123" ); // Works as expected

Is this intentional behaviour, and is it just the hidden attribute that stops a binding attachment?

Cheers,

Neil

BTW - I am now on 1.9.2.3705 ;-)

[Boris Zbarsky]

On 4/26/10 11:28 AM, neil.stansbury () redbacksystems ! com wrote:
> I know about this document:
> https://developer.mozilla.org/en/XBL/XBL_1.0_Reference/Binding_Attachment_and_Detachment
>
> But could someone clarify the circumstance under which an XBL binding is
> formally attached?

1) Whenever we try to construct a frame for it.
2) When it's first JS-wrapped, if it's in the document at the time or
is a clone of a XUL element that's in the document.

This, of course, just shifts the question to when #1 happens. The
answer there is "it depends".

> Given:
>
> <elem id="abc" hidden="true"/>

This is XUL, right? If so, hidden="true" means display:none, so no
attempt is made to construct frames for descendants.

> Both subsequent calls result in property "undefined" or "is not a
> function" warnings/errors. This also applies to the CSS display: none;

Right; see above.

> However, If the "hidden" attribute on the parent element is set via
> setAttribute() then the binding attachment works as expected.
>
> thus:
>
> abc.setAttribute( "hidden", "true" );
> abc.appendChild( xyz );

The behavior here "depends". In old enough Gecko, the style change is
processed synchronously and you won't get binding attachment here. In
newer Geckos, the style change is async while frame construction on DOM
insertion is sync, so the append creates a frame before the
hidden="true" takes effect. In even newer Geckos (m-c), frame
construction on DOM insert is also async, so then the question is how
it's ordered with restyle processing. I _think_ it happens before
restyle processing right now, but that's subject to change.

In general, the attachment model for XBL1 is more or less broken beyond
belief, especially when there are display:none subtrees around. It ends
up depending on the timing of GC invocations, on the timing of restyle
event processing, on what code you have between the setAttribute and
appendChild in your example above, etc.

-Boris

[Blair McBride]

On 27/04/2010 4:08 a.m., Boris Zbarsky wrote:
>> <elem id="abc" hidden="true"/>
>
> This is XUL, right? If so, hidden="true" means display:none, so no
> attempt is made to construct frames for descendants.

Also note that if you want the element to not be visible, but do want
the binding attached, use the collapsed attribute (equivalent in CSS to
visibility:collapse).

- Blair

[Neil]

Blair McBride wrote:

Although in this case the margins are still "visible", and there are
other odd side-effects e.g. menuitems are still keyboard navigable.

--
Warning: May contain traces of nuts.

["neil.stansbury () redbacksystems ! com"]

Hi Boris,

Thanks for this detailed description. It took me a while to realise that apparent setAttribute() effect was an artefact of the load order, and
re-style event timing as you suggested.

Interestingly I did try Blair's suggestion of collapsed="true" as an alternative originally, but still had layout problems as a result, which
sounds like Neil's warning.

It was a case of back to the drawing board again!

Cheers,

N