Perspective table: odd behavior when selecting a range with sorted column

Perspective on Ignition 8.0.12
Ubuntu 18.04
Firefox 76 and Chrome 80

What I did
I created a perspective table, made one of the columns sortable, and set the selection mode to “multiple interval”. When in a perspective session I click on the sortable column header to sort the data. Then I click a row and hold the shift key and click another row.

What I expected
I expected the range of visible rows between my two clicks to be selected.

What actually happened

I got what seemed to be a random set of selected columns. After further investigation, I noticed the rows selected weren’t random, but instead were the range formed as if I had clicked those two rows when the data had not been sorted.

Below is a screenshot of me doing this. I used the perspective table default data, made the city column sortable, set the selection mode to multiple interval. Then in a browser I clicked city to sort it ascending. Then I clicked on the row with “Abidjan” then shift-clicked the row with “Bandung”.

You can see "Berlin, “Chicago” and “Dar es Salaam” are highlighted, which I wouldn’t expect when selecting a range between the top two rows.

Additional information

If I click the city header twice more to remove the sort on the column, then I can see that the selected rows form a single range based on the original order of the data. So I know the selection isn’t random, it’s based on the data’s original order. Unfortunately that isn’t helpful because I want to select a range based on the sort that I applied, not the data’s original order.

I noticed the same problem happens when sorting on any column. It also happens when the selection mode is “single interval”.

I tried to reproduce in Ignition 8.1.0 and this issue seems to be fixed.

I’m surprised no one replied to this thread sooner. I just attempted to replicate it today believing that the original post was a new entry, but now I see that this was brought up quite some time ago. You are correct that this is no longer an issue in 8.1.0 or newer. It’s not clear when the fix was introduced, but I do see the desired behavior in current builds.

Also, excellent write-up; it was very easy to read and understand what you were encountering and expecting.