The default bug view has changed. See this FAQ.

output with value doesn't find context

RESOLVED FIXED

Status

Core Graveyard
XForms
RESOLVED FIXED
10 years ago
8 months ago

People

(Reporter: aaronr, Assigned: aaronr)

Tracking

({fixed1.8.0.12, fixed1.8.1.4})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

1.03 KB, application/xhtml+xml
Details
1.48 KB, patch
surkov
: review+
smaug
: review+
Details | Diff | Splinter Review
(Assignee)

Description

10 years ago
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.
(Assignee)

Updated

10 years ago
Blocks: 353738
(Assignee)

Comment 1

10 years ago
Created attachment 260325 [details] [diff] [review]
patch
Attachment #260325 - Flags: review?(surkov.alexander)
(Assignee)

Updated

10 years ago
Attachment #260325 - Flags: review?(Olli.Pettay)

Comment 2

10 years ago
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?
(Assignee)

Comment 3

10 years ago
(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

10 years ago
(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?
(Assignee)

Comment 5

10 years ago
(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.
(Assignee)

Comment 6

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

Updated

10 years ago
Attachment #260325 - Flags: review?(Olli.Pettay) → review+

Comment 7

10 years ago
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.
Attachment #260325 - Flags: review?(surkov.alexander) → review+
(Assignee)

Comment 8

10 years ago
checked into trunk yesterday
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Whiteboard: xf-to-branch
(Assignee)

Comment 9

10 years ago
checked into 1.8 branch on 2007-04-12
checked into 1.8.0 branch on 2007-04-16
Keywords: fixed1.8.0.12, fixed1.8.1.4
Whiteboard: xf-to-branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.