I was testing sorting in Chrome and I noticed that when sorting on a column with multiple values that are the same, some rows are moved by the sort unexpectedly. We tested the same thing in FireFox and the rows did not move. Is there an explanation for this, or something that we can do to stop this behavior?
I can not reproduce the problem. If you describe what is the problem more detail we can understand the problem – with other words what actions you do, what you expect and what is happen?
In Chrome I can not see any problem with the sorting.
When you deal with local data you missed a very important definition in colModel – key:true. Note that the key should be unique which can not be seen in your definition.
I am going to do my best to explain this without screen shots.
In FireFox, when the a sort is applied to the first column in the example, ‘Time Selection’, no rows move because the data was brought in presorted. This is our desired behaviour.
In Chrome, when the sort is applied to the first column the rows do move. The second row of data moves to the fifth row, and rows 3-5 all move up one. This causes issues because we can not predict what the outcome of the search will be.
I see the problem you point. To be a honest, this is not a jqGrid problem, but rather a way how different browsers apply the sort algorithm.
I have checked in our jqGrid code and it is according to the ECMA specifications – the sorting function return -1, 1, 0 which is correct, but… Chrome is exception.
This article (instead that it is old) is true today.
I have try to implement the idea mentioned in the discussion above, but Chrome has a totally unexpected behavior in the last version when we apply a sort to the object
I will try to apply another approach, but I do not promise that it will be ok.
This way we define a custom sortfunction to which we pass not only the compared values a,b, but the object value oa, ob.
The object value contain the index property which stores the indexes of the sorted rows to their historical insertion. I.e the index begin from 0 and end to the last record number.
Note that we do not compare for equality since we are sure that the indexes are unique.
I think it is a fix – not very good, but we have the same behavior in all browsers.
Please let us know if this is ok for you.
Kind Regards,
This reply was modified 9 years, 11 months ago by tony.