User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) Gecko/20070309 Firefox/220.127.116.11
This works on 4-17 trunk but can't get the 4-17 1.8 branch version to work.
This is normative W3C test case 10.1.12.c
Created attachment 261944 [details]
a bit of this was that the patch for bug 349643 wasn't marked to get moved to the branch so the QI to nsIXFormsEphemeralMessageUI failed in nsXFormsMessageElement::ShowEphemeral(). But even after I apply the patch and fixed it up to fit on the branch, the QI is still failing. Looking at the XBL bindings in the DOMInspector it looks like the right hierarchy is applied so the QI should work. But the anonymous content isn't in DOMInspector so something is going wrong somewhere. ugh, I hope this isn't another xbl bug that got fixed in the trunk but not on the branch.
Created attachment 262964 [details] [diff] [review]
The problem turned out to be that since xf:action contains xf:message and xf:action ISN'T inherited from nsIXTFBindableElement, then that would prevent any XBL that is supposed to bind to the xf:message from actually attaching. But if that same xf:message were outside of an xf:action, it would work fine. This patch fixes the problem by making nsXFormsActionElement inherit from nsXFormsBindableControlStub. I don't know if that is the right answer, though. Perhaps we should move the Get/Set/UpdateRepeatState from nsXFormsBindableControlStub into nsXFormsBindableStubElement and have nsXFormsActionElement inherit from that.
Comment on attachment 262964 [details] [diff] [review]
bah, problem with the patch. Had part of another patch in it.
Created attachment 262967 [details] [diff] [review]
this one will work
Doesn't make sense to move Get/Set/UpdateRepeatState to nsXFormsBindableStub since they need mHasParent and mHasDoc, which are also needed by nsXFormsControlStubBase which doesn't inherit from nsXFormsBindableStub. So I'll make nsXFormsActionElement inherit from nsXFormsBindableControlStub and override the parts of nsXFormsControlStubBase, etc. that don't make sense for nsXFormsActionElement. For example, GetUsesSingleNodBinding is certainly not PR_TRUE for action element.
Created attachment 263055 [details] [diff] [review]
action has no binding attrs so most of the functions inherited via nsXFormsControlStubBase won't apply to it so I think we are safe not stubbing them all out. Action should manage its own mHasParent and mHasDoc because calling into parent class' ::ParentChanged and ::DocumentChanged adds overhead that it doesn't need. Dropped mElement from nsXFormsActionElement since it will pick it up from nsXFormsControlStubBase, now.
checked into 1.8 and 1.8.0 branches