Attached test case that shows the current behavior.

Steps:

• Load welcomeICEfaces.iface
• Move the paginator to page 2.
• Click the "List Two" button, paginator is reset to page one.

Committed fix to trunk at revision 36619. Added 'checkPageConsistency' attribute.

The new behaviour wasn't actually to reset to the first page. The code added for ICE-8610 was simply to check the page consistency of the paginator at render time. What happens is that this is sensitive to the order in which the new data model is evaluated. In this test case, the paginator component came BEFORE the table on the page, and it went through the render phase first. After the data model was changed, it wasn't available before the table went through the render phase, and the ensureFirstRowInRange() method gets the idea that the data model is empty, and so it resets to the first page. If the paginator is placed AFTER the table, the new data model is available by the time the paginator goes through the render phase, and in this case, the page stays the same after the change in the data model. In fact, the logic of ensureFirstRowInRange() is to only reset to the first page if there are no rows available and to set the paginator to the last available page if the new data model has fewer rows. The issue with ICE-8610 was also sensitive to the order in which things were evaluated. It seems like after a change in the data model, the table has to go through the render phase in order to completely set up the new data model. It might be possible to do something about this at the app level, if the original data model is not cleared first in the action listener method. Anyway, in order to support both the new and old behaviours, the attribute 'checkPageConsistency' was added. In other words, this attribute controls whether ensureFirstRowInRange() is called or not.

Confirmed new attribute functionality using the attached test application with ICEfaces EE 1.8.2.GA_P07 build2 jars. Tested in IE 6/7/8/9/10, Firefox 17/21, Chrome 27.