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.
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.
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).
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.
Heck, I'll assign it to myself to fix. I've already done this much debugging on it... :-)
Created attachment 255727 [details] testcase3 also affects xf:itemset's for the same reason as repeats.
Created attachment 255733 [details] [diff] [review] patch
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?
(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 on attachment 255733 [details] [diff] [review] patch please update guid
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.
Created attachment 255958 [details] [diff] [review] patch2 changed guid
Comment on attachment 255958 [details] [diff] [review] patch2 I thought I had reviewed this already. How strange :)
checked into trunk
checked into 1.8 branch on 2007-04-12 checked into 1.8.0 branch on 2007-04-16