40985 - XBL widgets should not assume they know where anonymous items are

Status: RESOLVED FIXED

(Core :: XUL, defect, P3)

Description

[Ben Goodger (use ben at mozilla dot org for email)]

textfield XBL uses this.anonymousContent[0].firstChild etc. This is not 
skinnable because if the anonymous content changes in the skin then the 
javascript will break and textfields stop working. (this is bad :)

need to rewrite js in such a way that it walks anonymous children looking for 
html:input element rather than making assumptions about where it is.

Comment 1

[Peter Trudelle]

[need info] Under what circumstances does this happen, and what breaks?

Comment 2

[John Morrison]

I spoke with Ben about, but errors in this explanation are mine :-]

A skin author could choose to implement a new XBL binding for <textfield>
which derives from the base definition for <textfield> (i.e., Ben's version),
and adds to or re-orders the anonmymous content of the derived definition 
(e.g., to achieve some visual or usability effect).

However, as a _skin_, the author will not be able to change the API's (cannot
add script for security reasons) and will depend on the base API's to do the
right thing. As things currently stand, the base API's depend on a specific
ordering of the binding's anonymous content. Hence, the author's skin will be 
busted.

This same principle applies to all XBL bindings.

Comment 3

[Phil Peterson]

[nsbeta2-] assuming this doesn't impact our ability to deliver the Classic or 
Modern skins for beta2. If this bug breaks either of those skins, please 
renominate.

Comment 4

[don]

M20

Comment 5

[johng]

nav triage team:
reassigning to hangas to get more information [NEED INFO].  If we do not fix 
this, will we break 3rd party skins?  nsbeta3

Comment 6

[hangas]

Yes this could break third party skins.  We use XBL to define widgets.  The 
"rule" is that we should not use knowledge of XBL in the content (XUL/JS) or in 
other CSS/XBL because then various skin combinations would break the application.  
It would be possible to make a simple change to appearance of text fields in a 
skin and have the use of that skin break the app.  

I recommend that we fix these in all places where problems come up during 
development of a third party skin.  It would be nice to fix these as we find them 
but we should probably focus on those that surface and just keep this bug in the 
system to be fixed when we have time.  So lets go with minus unless we see a 
problem with a third party skin.

Comment 7

[hangas]

Marking fixed.  I believe the initial issues have been resolved.  While there may 
be other issues I am not currently aware of any.  Ben can you mark verified?