Last Comment Bug 318779 - index() update problem in repeat on nodeset change
: index() update problem in repeat on nodeset change
Status: RESOLVED FIXED
: fixed1.8.0.5, fixed1.8.1
Product: Core Graveyard
Classification: Graveyard
Component: XForms (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: Allan Beaufour
: Stephen Pride
Mentors:
Depends on: 334015
Blocks: 331209
  Show dependency treegraph
 
Reported: 2005-12-02 12:27 PST by Aurelian Penciu
Modified: 2016-07-15 14:46 PDT (History)
3 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Testcase (7.07 KB, application/xml)
2005-12-02 12:30 PST, Aurelian Penciu
no flags Details
Revised testcase (3.54 KB, application/xhtml+xml)
2006-04-19 09:43 PDT, Allan Beaufour
no flags Details

Description Aurelian Penciu 2005-12-02 12:27:15 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051202 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051202 Firefox/1.6a1

The index() of a nested repeat is not set correctly after a random number of insert/delete operations on several nested repeat elements. 

The problem occurs when using nested repeat elements (the nested repeat uses a rather complex XPath expression to filter out items marked as deleted or hidden). 

After several insert/delete cycles (items are inserted in the nested repeat for different outer repeat items), if the user alternates deleting inner items from more than one outer items the index of the nested repeat fails to be set properly (actually it is correct only for one of the nested repeat elements and does not change for the others).

An example to clarify the issue will be provided.  

Reproducible: Sometimes

Steps to Reproduce:
Using the attached test case
1. Click on "Add 10 Items" for each of the four items of the outer repeat element.
2. The middle panel should show the filtered collection while the right panel should show the unfiltered version.
3. Start deleting items (click on Delete) in the following orther:
 - first the last item (10) of Item list#4
 - then the last item (10)  of Item list#3
 - then the last item (10)  of Item list#2
 - then the last item (10)  of Item list#1
 - now delete the last item (9) of Item list#1
 - try to delete the last item (9) of Item list#2 (failed for me)
4. Check the value of the nested repeat index (second value listed in the first panel) and notice that it is not updated when clicking on Delete (as it used to happen until this point).

The problem occurs after other random insert/delete patterns the only commonality seeming to be that operations are performed on several nested repeat  elements.
Actual Results:  
The nested repeat index() is not computed properly after a number of insert/delete  operations. At this point items from the nested repeat elements cannot be referenced properly.

Expected Results:  
Be consistent. Keep setting the index properly.

The problem does not seem to exist on simple xf:repeat elements (or at least it's extremely difficult to reproduce).
Comment 1 Aurelian Penciu 2005-12-02 12:30:00 PST
Created attachment 204821 [details]
Testcase

As explained in the bug description.
Comment 2 Allan Beaufour 2005-12-06 18:36:08 PST
Just skimming this, we do not actually handle repeat-index settting on insert/delete properly at all, that's bug 282828. So if you are getting correct behaviour sometimes, consider yourself lucky :) If that is what you are saying, please dupe this bug to 282828. If not, correct me and I will investigate further.
Comment 3 Aurelian Penciu 2005-12-07 07:02:19 PST
(In reply to comment #2)
> Just skimming this, we do not actually handle repeat-index settting on
> insert/delete properly at all, that's bug 282828. So if you are getting correct
> behaviour sometimes, consider yourself lucky :) If that is what you are saying,
> please dupe this bug to 282828. If not, correct me and I will investigate
> further.
> 
It's not the ::repeat-index pseudoelement (XForms 1.0 - F.2) that bothers me :-(. The index() function starts failing after "repeated abuse". The "abuse pattern" I managed to reproduce was to have a list of lists (master-detail) and keep inserting/deleting detail items into different masters. 

It looks like it's the fact that I place a delete trigger on each line and I expect that clicking on it would --as a side effect-- set both indices (master and detail) correctly (E.g. clicking on a(2,3) would set the master index to 2 and the detail index to 3). Once in a while it doesn't.

If this is indeed related to the repeat-index bug 282828 or to bug 302922 (I'll try to read the code but it will take some time) please confirm and I will definitely mark this as a duplicate.
Comment 4 Allan Beaufour 2006-02-07 08:59:14 PST
Sorry that it has taken me so darn long to get to this!

(In reply to comment #3)
> (In reply to comment #2)
> > Just skimming this, we do not actually handle repeat-index settting on
> > insert/delete properly at all, that's bug 282828. So if you are getting correct
> > behaviour sometimes, consider yourself lucky :) If that is what you are saying,
> > please dupe this bug to 282828. If not, correct me and I will investigate
> > further.
> > 
> It's not the ::repeat-index pseudoelement (XForms 1.0 - F.2) that bothers me
> :-(. The index() function starts failing after "repeated abuse". The "abuse
> pattern" I managed to reproduce was to have a list of lists (master-detail) and
> keep inserting/deleting detail items into different masters. 
> 
> It looks like it's the fact that I place a delete trigger on each line and I
> expect that clicking on it would --as a side effect-- set both indices (master
> and detail) correctly (E.g. clicking on a(2,3) would set the master index to 2
> and the detail index to 3). Once in a while it doesn't.

Well, relying on insert and delete to set the indexes correctly is exactly what bug 282828 is about. They do not. BUT as far as I can understand, your problem is that the "Delete" buttons suddenly stop working, right?

If that is your problem then your are not hitting bug 282828, because when you click a trigger inside a repeat row, the index should be set to that repeat row because it receives focus, thus eliminating the need for insert/delete to adjust indexes. I'll look into that.
Comment 5 Allan Beaufour 2006-04-19 09:29:27 PDT
It's still there. And it does not even have to be nested repeats.
Comment 6 Allan Beaufour 2006-04-19 09:43:14 PDT
Created attachment 219009 [details]
Revised testcase
Comment 7 Allan Beaufour 2006-05-24 00:33:28 PDT
Fixed by bug 334015

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