Testcase from Leigh. Bug found by Leigh. Looks like if we have a xf:output with @value that gets its context from a containing control, we don't find the context correctly so binding won't work since it will get the document element node as the context instead of the one set by the contextcontrol. I debugged this. It is because we call BindToModel on xf:output with @value while other controls are having theirs deferred because the model's not ready, yet. So we put the output in the model's control list before the contextcontrol is in the list. So when it finally comes time to bind the controls (when InitializeControls is called), it will be in the model's control list before the contextcontrol so when it asks the contextcontrol for its bound node, it won't have it yet.

Looks like workaround. I'm sorry but why can't we handle @value like we do @ref :)? In any way why we can't check whether model is ready before output is bound to the model in your approach?

(In reply to comment #2) > Looks like workaround. I'm sorry but why can't we handle @value like we do @ref > :)? Can't handle @value like @ref because using a binding attribute means special things like providing context to contained xforms elements, determining if the control has a bound node, etc. @value doesn't fit in these cases. > In any way why we can't check whether model is ready before output is bound > to the model in your approach? > We can check it that way if you want, but currently the only check for it is inside the binding code. Pulling the test out means that we are doing it in yet another place, that's all. Plus, this test is only ever going to fail during initialization. So we'd be making the check twice for every time that the xf:output goes through ::Bind, when we really only need to check it during initialization. We could introduce a PRBool member variable if you want to track if this extra defferred binding test ever passes and just test against that. Let me know which way you want me to go with this.

(In reply to comment #3) > (In reply to comment #2) > > Looks like workaround. I'm sorry but why can't we handle @value like we do @ref > > :)? > > Can't handle @value like @ref because using a binding attribute means special > things like providing context to contained xforms elements per bug 305196 it seems to be valid. >, determining if the > control has a bound node, etc. @value doesn't fit in these cases. What's about bound node and etc?

(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > Looks like workaround. I'm sorry but why can't we handle @value like we do @ref > > > :)? > > > > Can't handle @value like @ref because using a binding attribute means special > > things like providing context to contained xforms elements > > per bug 305196 it seems to be valid. > > >, determining if the > > control has a bound node, etc. @value doesn't fit in these cases. > > What's about bound node and etc? > ? I don't get what you mean. Bug 305196 outlines most of the reasons why we can't treat @value like a binding attribute. output with @value does provide context for its contained xforms elements, but the mBoundNode for that output isn't really a bound node, but rather just remembering the context node that the output used to evaluate its @value. So that way if a contained element asks this output for its context, it will pass on this remembered context (since it really doesn't have a bound node). Things that a bound xforms control would have associated with it that a output with only @value wouldn't are things like the intrinsic states (readonly, disabled, etc), the list of dependencies (mDependencies) to determine whether we need to refresh the output or not, and the mozType bound node type stored on the control. GetBoundNode will also return nothing and GetHasBoundNode will return PR_FALSE.

Alex, Olli, any chance you can get this reviewed today or tomorrow? Otherwise I'll move it to 0.9. Thanks.

Comment on attachment 260325 [details] [diff] [review] patch (In reply to comment #3) > Let me know which way you want me to go with this. > I'm fine with your approach.

checked into trunk yesterday

checked into 1.8 branch on 2007-04-12 checked into 1.8.0 branch on 2007-04-16