Last Comment Bug 376217 - output with value doesn't find context
: output with value doesn't find context
Status: RESOLVED FIXED
: fixed1.8.0.12, fixed1.8.1.4
Product: Core
Classification: Components
Component: XForms (show other bugs)
: unspecified
: x86 Windows XP
: -- normal (vote)
: ---
Assigned To: aaronr
: Stephen Pride
Mentors:
Depends on:
Blocks: 353738
  Show dependency treegraph
 
Reported: 2007-04-01 23:26 PDT by aaronr
Modified: 2007-04-23 16:33 PDT (History)
1 user (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (1.03 KB, application/xhtml+xml)
2007-04-01 23:26 PDT, aaronr
no flags Details
patch (1.48 KB, patch)
2007-04-02 00:23 PDT, aaronr
surkov.alexander: review+
bugs: review+
Details | Diff | Review

Description aaronr 2007-04-01 23:26:54 PDT
Created attachment 260321 [details]
testcase

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.
Comment 1 aaronr 2007-04-02 00:23:17 PDT
Created attachment 260325 [details] [diff] [review]
patch
Comment 2 alexander :surkov 2007-04-02 08:46:22 PDT
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?
Comment 3 aaronr 2007-04-02 11:48:24 PDT
(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.
Comment 4 alexander :surkov 2007-04-02 12:15:55 PDT
(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?
Comment 5 aaronr 2007-04-02 14:56:29 PDT
(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.
Comment 6 aaronr 2007-04-04 15:31:22 PDT
Alex, Olli, any chance you can get this reviewed today or tomorrow?  Otherwise I'll move it to 0.9.  Thanks.
Comment 7 alexander :surkov 2007-04-04 18:49:58 PDT
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.
Comment 8 aaronr 2007-04-06 02:06:51 PDT
checked into trunk yesterday
Comment 9 aaronr 2007-04-23 16:33:37 PDT
checked into 1.8 branch on 2007-04-12
checked into 1.8.0 branch on 2007-04-16

Note You need to log in before you can comment on or make changes to this bug.