[GH-ISSUE #1158] Selection is lost when removing filters #1152

New issue

Open

opened 2026-03-03 19:48:47 +03:00 by kerem · 2 comments

kerem commented

2026-03-03 19:48:47 +03:00

Owner

Originally created by @IMNilesAZ on GitHub (Feb 24, 2022).
Original GitHub issue: https://github.com/ProxymanApp/Proxyman/issues/1158

Originally assigned to: @NghiaTranUIT on GitHub.

When you de-select a filter,

Proxyman version? (Ex. Proxyman 1.4.3)

3.1.0

macOS Version? (Ex. mac 10.14)

12.2

Steps to reproduce

add one or more filters
select a row
remove one of your filters
note that a completely different row is now selected. The same "ROW INDEX" in the table might be selected, but not the same "LINE OF DATA" that had previously been selected.

Expected behavior

I would expect the current line to remain selected and in view when removing a filter, because I probably used the filter to find a particular line, and then removed the filter so that I could see the surrounding context, but this context is lost when removing the filter. it looks like you're just preserving maybe the table row index, but what you really should be doing is preserving "the line of data that was selected" (assuming it's still in the data, which it should be if you are REMOVING a filter).

Screenshots (optional)

Originally created by @IMNilesAZ on GitHub (Feb 24, 2022). Original GitHub issue: https://github.com/ProxymanApp/Proxyman/issues/1158 Originally assigned to: @NghiaTranUIT on GitHub. When you de-select a filter, ### Proxyman version? (Ex. Proxyman 1.4.3) 3.1.0 ### macOS Version? (Ex. mac 10.14) 12.2 ### Steps to reproduce add one or more filters select a row remove one of your filters note that a completely different row is now selected. The same "ROW INDEX" in the table might be selected, but not the same "LINE OF DATA" that had previously been selected. ### Expected behavior I would expect the current line to remain selected and in view when removing a filter, because I probably used the filter to find a particular line, and then removed the filter so that I could see the surrounding context, but this context is lost when removing the filter. it looks like you're just preserving maybe the table row index, but what you really should be doing is preserving "the line of data that was selected" (assuming it's still in the data, which it should be if you are REMOVING a filter). ### Screenshots (optional)

kerem added the

enhancement

label

2026-03-03 19:48:47 +03:00

kerem commented

2026-03-03 19:48:49 +03:00

Author

Owner

@NghiaTranUIT commented on GitHub (Feb 25, 2022):

Your observation is correct. The reason why we reset the row index as soon as the filter is updated is that it's really difficult to maintain the previous selection.

Technically, when reloading the table view, all selection data would be wiped out. To maintain the previous selection, I have to look up it again in the huge data source. Since the table view is already sorted by a particular column, might be we can efficiently find it by using the binary search.

I'd open this ticket and implement it soon 👍

@NghiaTranUIT commented on GitHub (Feb 25, 2022): Your observation is correct. The reason why we reset the row index as soon as the filter is updated is that it's really difficult to maintain the previous selection. Technically, when reloading the table view, all selection data would be wiped out. To maintain the previous selection, I have to look up it again in the huge data source. Since the table view is already sorted by a particular column, might be we can efficiently find it by using the binary search. I'd open this ticket and implement it soon 👍

kerem commented

2026-03-03 19:48:49 +03:00

Author

Owner

@IMNilesAZ commented on GitHub (Feb 25, 2022):

Great. I suspect that even if you had to do a linear search, finding the index column (or whatever it’s called) value in the data source (without involving the table necessarily) wouldn’t take as long as you think on a modern desktop :)

@IMNilesAZ commented on GitHub (Feb 25, 2022): Great. I suspect that even if you had to do a linear search, finding the index column (or whatever it’s called) value in the data source (without involving the table necessarily) wouldn’t take as long as you think on a modern desktop :)