Last Comment Bug 362308 - repeat doesn't update on value changes
: repeat doesn't update on value changes
Status: RESOLVED FIXED
: fixed1.8.0.12, fixed1.8.1.4
Product: Core Graveyard
Classification: Graveyard
Component: XForms (show other bugs)
: Trunk
: x86 All
: -- normal (vote)
: ---
Assigned To: aaronr
: Stephen Pride
:
Mentors:
Depends on:
Blocks: 353738
  Show dependency treegraph
 
Reported: 2006-11-29 17:38 PST by aaronr
Modified: 2016-07-15 14:46 PDT (History)
1 user (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
testcase (2.01 KB, application/xhtml+xml)
2006-11-29 17:38 PST, aaronr
no flags Details
testcase2 (2.53 KB, application/xhtml+xml)
2007-01-05 17:30 PST, aaronr
no flags Details
testcase3 (2.37 KB, application/xhtml+xml)
2007-02-19 14:55 PST, aaronr
no flags Details
patch (7.85 KB, patch)
2007-02-19 16:32 PST, aaronr
surkov.alexander: review+
Details | Diff | Splinter Review
patch2 (8.31 KB, patch)
2007-02-21 16:02 PST, aaronr
bugs: review+
Details | Diff | Splinter Review

Description aaronr 2006-11-29 17:38:21 PST
If the value of a node is changed (for example, via a xf:input) and that node is one of the nodes in a repeat's nodeset, the repeat doesn't reflect this change.
Comment 1 aaronr 2006-11-29 17:38:53 PST
Created attachment 247017 [details]
testcase
Comment 2 aaronr 2006-12-05 01:07:06 PST
Looks like the problem is related to using @bind on the repeat element.  If we use @nodeset, then it works.  The issue is that if a repeat uses @bind, then mUsesModelBinding is PR_TRUE.  Yet it won't have a boundNode (since it is potentially bound to more than one node, really).  Thus nsXFormsModelElement::RefreshSubTree won't navigate down inside the nsXFormsRepeatElement's controlListItem looking for any children that might possibly need refreshed.  Instead we go on to the next sibling in the model's control list.  But when repeat uses @nodeset, then mUsesModelBinding is PR_FALSE so we don't enter into that test.  Now I need to sit and figure out what the proper behavior should be.
Comment 3 aaronr 2007-01-05 17:30:05 PST
Created attachment 250663 [details]
testcase2

please verify that this testcase works, too, when the fix is eventually tested.  I think it fails due to the same core problem that this bug addresses.  Testcase comes from Leigh (simplified version of Martin's testcase).
Comment 4 aaronr 2007-01-24 18:58:00 PST
Thanks to a wonderful explanation of a section of RefreshSubTree by Allan, I think I'm on the right track.  I think that we are preventing ourselves from refreshing children of the repeat because we think that in cases where an element has a @bind (mUsesModelBinding) but doesn't have a bound node, then the parent will be hidden and thus so will all the children so no reason to refresh them.  And since it is a @bind instead of a @ref on the element, we don't have to worry about possibly having to rebind the element (if a dependency is dirty) since @bind nodesets are only refreshed on construction and during rebuilds.  Normal node value changing won't cause any kind of a rebind opportunity.
Comment 5 aaronr 2007-01-24 18:59:20 PST
Heck, I'll assign it to myself to fix.  I've already done this much debugging on it... :-)
Comment 6 aaronr 2007-02-19 14:55:25 PST
Created attachment 255727 [details]
testcase3

also affects xf:itemset's for the same reason as repeats.
Comment 7 aaronr 2007-02-19 16:32:43 PST
Created attachment 255733 [details] [diff] [review]
patch
Comment 8 alexander :surkov 2007-02-19 19:41:59 PST
I guess usesSingleNodeBinding should depend on xpath expression result type rather than tagname of control. In futrue when xforms is allowed to bind to element of foreign namespaces then it will be needed thing. Can we use type of binding to instance node instead?
Comment 9 aaronr 2007-02-20 11:30:58 PST
(In reply to comment #8)
> I guess usesSingleNodeBinding should depend on xpath expression result type
> rather than tagname of control. In futrue when xforms is allowed to bind to
> element of foreign namespaces then it will be needed thing. Can we use type of
> binding to instance node instead?
> 

no, because @bind exists in both single node binding and node set binding.  I'd say that we'd have to wait to see how a foreign-namespaced element will determine whether it is using a single node binding or a node-set binding.  Probably a question for the CDF WG, though I'll also ask the XForms working group.
Comment 10 alexander :surkov 2007-02-21 09:46:37 PST
Comment on attachment 255733 [details] [diff] [review]
patch

please update guid
Comment 11 aaronr 2007-02-21 15:40:25 PST
link for W3C post on the subject of how a processor is supposed to know if @bind is a node-set bind or a single-node bind on foreign namespaces elements: http://lists.w3.org/Archives/Public/www-forms/2007Feb/0101.html.  Hopefully this will generate some discussion.
Comment 12 aaronr 2007-02-21 16:02:32 PST
Created attachment 255958 [details] [diff] [review]
patch2

changed guid
Comment 13 Olli Pettay [:smaug] 2007-03-05 11:07:05 PST
Comment on attachment 255958 [details] [diff] [review]
patch2

I thought I had reviewed this already. How strange :)
Comment 14 aaronr 2007-03-15 19:06:39 PDT
checked into trunk
Comment 15 aaronr 2007-04-23 16:17:53 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.