Most controls will have this trouble. Bug reported by Mark Seaborne. If you have a control inside a repeat (even a single repeat) and that control contains a label that contains inline text and/or inline xf:output element, then the output element part won't show up.
Bug is not recreatable outside of a repeat. Also, bug is only recreatable on the trunk. So it is caused by something that is still in xf-to-branch mode. I'm guessing that it has to do with Doron's accesskey change for labels. I'm still working on narrowing it down, though.
Created attachment 208124 [details]
Doron and I found a workaround. If you change the code for output.refresh in xforms.xml to not set the value using textContent, but rather add a space to the anonymous span and then set the span's value during refresh using span.firstChild.nodeValue = this.stringValue, then it works just fine. I'll look more at it tomorrow.
Created attachment 208291 [details] [diff] [review]
patch for workaround
I debugged all through nsGenericElement::SetTextContent and I don't see a failure and after we set the span's textContent, the textnode has the correct value and is in the document and properly parented beneath the repeat's contextcontainer element so it should definitely be visible. But it isn't showing up.
I also noticed that if I did all of this by hand (create a text node, give it the value out of this.stringValue and insert it as a child of the anonymous span) that the textnode still doesn't show up. So at Doron's suggestion, the workaround is to initialze the anonymous span with a textnode through XBL and just change the nodeValue for it during output's refresh.
So here is a workaround that does just that. Given our past experiences with XTF and XBL co-existing, I'm assuming that this won't be needed after repeat is XBL-ized.
Comment on attachment 208291 [details] [diff] [review]
patch for workaround
This is not a bad hack. Actually this should be a bit faster way to update the value of the <output> than the old .textContent ;)
checked into trunk
checked into MOZILLA_1_8_BRANCH via bug 323691. Leaving open for now until it gets into 1.8.0
verified fixed in MOZILLA_1_8_BRANCH