383776 - Cannot add anonymous content to form controls

Status: RESOLVED WONTFIX

(Core :: XBL, defect)

Description

[Dean Edwards]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Build Identifier: 1.9a6pre: 2007060704

Cannot use XBL to add anonymous content to form controls. This affects all form controls: <input>, <select>, <textarea> and <button>.

Reproducible: Always

Steps to Reproduce:
1. Sample Markup:
<div class="test">text</div>
<input class="test" type="text" value="text">
2. Binding:
<style type="text/css">
 *.test {-moz-binding: url(test.xml#test);}
</style>
3. XBL:
<?xml version="1.0"?>
<bindings xmlns="http://www.mozilla.org/xbl" xmlns:html="http://www.w3.org/1999/xhtml">
<binding id="test">
 <content>
  <html:div>BEFORE: Anonymous content</html:div>
  <children />
  <html:div>AFTER: Anonymous content</html:div>
 </content>
</binding>
</bindings>
Actual Results:  
BEFORE: Anonymous content
text
AFTER: Anonymous content
 --------------------
| text               |
 --------------------

Expected Results:  
BEFORE: Anonymous content
text
AFTER: Anonymous content
BEFORE: Anonymous content
 --------------------
| text               |
 --------------------
AFTER: Anonymous content

This needs to be fixed for the Web Forms 2.0 implementation which will use XBL to extend the GUI of the new input controls (date pickers, sliders etc).

Comment 1

[Boris Zbarsky [:bzbarsky]]

Attachment: The XBL

Comment 2

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase

Comment 3

[Boris Zbarsky [:bzbarsky]]

So the thing is that this <input> frame is a leaf frame.  Leaf frames get no child frame construction of any sort, including DOM children, XBL children, whatever.  Same thing for any other replaced element.  Try <img>, e.g.

Put another way, I'm not sure why your expected results are what they are.  They definitely don't make sense in terms of the flattened tree model XBL2 is using, nor in the approximation to it that XBL1 uses.

Comment 4

[Boris Zbarsky [:bzbarsky]]

You _might_ get the effect you want by using xbl:extends, until that's disabled for untrusted bindings for security reasons (which will hopefully be really soon now).  But then you won't have the actual "type in me" part of the control, though you might be able to fake it with an anonymous <input> in there...

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Hmm.. we should allow this somehow. It would be great if the CSS model delt with replaced elements in such a way that you could override the behavior and get a simple display:block frame.

Comment 6

[Boris Zbarsky [:bzbarsky]]

We could totally do that with a -moz style property if you want, fwiw.  Basically skip over all but the ConstructFrameByDisplayType parts of ConstructFrameInternal.

Comment 7

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

Really all the form controls should have their own values of 'display' and frames should be constructed only by 'display', but I don't think anybody's done that since IE5/Mac, and it would probably break the Web if we did it today (although maybe not).

Comment 8

[Dean Edwards]

This seems to be a duplicate of this bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=344615

Comment 9

[Boris Zbarsky [:bzbarsky]]

Why?  That bug is about implementing a particular type of input; not really related to XBL at all.  The proposal there is to change the C++ code in Gecko to do it.

Comment 10

[Dean Edwards]

My bad.

Comment 11

[Martijn Wargers (dead)]

Bug 296931 is probably related to this.

Comment 12

[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.