[GH-ISSUE #1697] Selection of multiple Apps and/or Domains should apply appropriate filtering to the requests view

kerem commented

2026-03-03 19:53:29 +03:00

Owner

Originally created by @seidnerj on GitHub (Jun 28, 2023).
Original GitHub issue: https://github.com/ProxymanApp/Proxyman/issues/1697

Originally assigned to: @NghiaTranUIT on GitHub.

Description

Right now, when one clicks any app/domain on the left hand side, the requests list is filtered accordingly. However, when selecting multiple apps and/or domains, the filtering applied is only for the last selected app/domain.

Why this feature/change is important?

The current behavior is confusing and counter-intuitive, especially given the single-selection behavior. I addition, it is very useful to be able to select multiple apps and/or domains and view the relevant requests list.

Originally created by @seidnerj on GitHub (Jun 28, 2023). Original GitHub issue: https://github.com/ProxymanApp/Proxyman/issues/1697 Originally assigned to: @NghiaTranUIT on GitHub. ## Description Right now, when one clicks any app/domain on the left hand side, the requests list is filtered accordingly. However, when selecting multiple apps and/or domains, the filtering applied is only for the last selected app/domain. ## Why this feature/change is important? The current behavior is confusing and counter-intuitive, especially given the single-selection behavior. I addition, it is very useful to be able to select multiple apps and/or domains and view the relevant requests list.

kerem added the

enhancement

✅ Done

labels

2026-03-03 19:53:29 +03:00

kerem commented

2026-03-03 19:53:30 +03:00

Author

Owner

@jalmaas commented on GitHub (Jan 11, 2024):

Was going to post this as a bug because I thought it used to work how you describe wanted behaviour, but maybe it's been like this all along? Needless to say I agree that current behaviour is counter-intuitive and being able to select multiple apps and/or domains would be really nice!

@jalmaas commented on GitHub (Jan 11, 2024): Was going to post this as a bug because I thought it used to work how you describe wanted behaviour, but maybe it's been like this all along? Needless to say I agree that current behaviour is counter-intuitive and being able to select multiple apps and/or domains would be really nice!

kerem commented

2026-03-03 19:53:30 +03:00

Author

Owner

@seidnerj commented on GitHub (Jan 11, 2024):

I think it's always been like this. Very counterintuitive. This combined with selection remaining when deleting a bunch of requests is definitely the top 2 most annoying things using Proxyman which is otherwise an amazing product.

@seidnerj commented on GitHub (Jan 11, 2024): I think it's always been like this. Very counterintuitive. This combined with selection remaining when deleting a bunch of requests is definitely the top 2 most annoying things using Proxyman which is otherwise an amazing product.

kerem commented

2026-03-03 19:53:31 +03:00

Author

Owner

@NghiaTranUIT commented on GitHub (Jan 11, 2024):

This combined with selection remaining when deleting a bunch of requests is definitely the top 2 most annoying things using Proxyman which is otherwise an amazing product.

@seidnerj can you share with me the video or screenshot to show it ?

Currently, after deleting a list of selected requests in the main table -> The Selection is remained is correct behavior from macOS.

I'm not sure what you expect: Reset the index to 0 🤔

@NghiaTranUIT commented on GitHub (Jan 11, 2024): > This combined with selection remaining when deleting a bunch of requests is definitely the top 2 most annoying things using Proxyman which is otherwise an amazing product. @seidnerj can you share with me the video or screenshot to show it ? Currently, after deleting a list of selected requests in the main table -> The Selection is remained is correct behavior from macOS. I'm not sure what you expect: Reset the index to 0 🤔

kerem commented

2026-03-03 19:53:31 +03:00

Author

Owner

@NghiaTranUIT commented on GitHub (Jan 11, 2024):

Was going to post this as a bug because I thought it used to work how you describe wanted behaviour, but maybe it's been like this all along? Needless to say I agree that current behaviour is counter-intuitive and being able to select multiple apps and/or domains would be really nice!

it's not a bug. It's a limitation of the app.

We allow multiple selections, so we can delete many domains/apps easily. However, it doesn't combine all requests from these selected domains/apps.

@NghiaTranUIT commented on GitHub (Jan 11, 2024): > Was going to post this as a bug because I thought it used to work how you describe wanted behaviour, but maybe it's been like this all along? Needless to say I agree that current behaviour is counter-intuitive and being able to select multiple apps and/or domains would be really nice! it's not a bug. It's a limitation of the app. We allow multiple selections, so we can delete many domains/apps easily. However, it doesn't combine all requests from these selected domains/apps.

kerem commented

2026-03-03 19:53:31 +03:00

Author

Owner

@seidnerj commented on GitHub (Jan 11, 2024):

This combined with selection remaining when deleting a bunch of requests is definitely the top 2 most annoying things using Proxyman which is otherwise an amazing product.

@seidnerj can you share with me the video or screenshot to show it ?

Currently, after deleting a list of selected requests in the main table -> The Selection is remained is correct behavior from macOS.

I'm not sure what you expect: Reset the index to 0 🤔

Attached a video below. The scenario is you select a bunch of requests, then delete them, but after the deletion the selection persists and now other requests are selected. This might make sense when you only selected a single request, the selection just moves to the next one that's available but when there are multiple requests - its confusing because you are now selecting a bunch of random requests. After deletion I would expect the selection to behave as follows:

For a single request, move the selection to the next available request, if such exists.
For multiple consecutive requests - move to the next available request, that's after the last selected request.
For multiple non-consecutive requests - eliminate all selection, no rows will be selected after the deletion.

Makes sense?

https://github.com/ProxymanApp/Proxyman/assets/4147381/3fb9e5fb-1f98-43e2-a934-923d57e5e01f

@seidnerj commented on GitHub (Jan 11, 2024): > > This combined with selection remaining when deleting a bunch of requests is definitely the top 2 most annoying things using Proxyman which is otherwise an amazing product. > > @seidnerj can you share with me the video or screenshot to show it ? > > Currently, after deleting a list of selected requests in the main table -> The Selection is remained is correct behavior from macOS. > > I'm not sure what you expect: Reset the index to 0 🤔 Attached a video below. The scenario is you select a bunch of requests, then delete them, but after the deletion the selection persists and now other requests are selected. This might make sense when you only selected a single request, the selection just moves to the next one that's available but when there are multiple requests - its confusing because you are now selecting a bunch of random requests. After deletion I would expect the selection to behave as follows: 1. For a single request, move the selection to the next available request, if such exists. 2. For multiple consecutive requests - move to the next available request, that's after the last selected request. 3. For multiple non-consecutive requests - eliminate all selection, no rows will be selected after the deletion. Makes sense? https://github.com/ProxymanApp/Proxyman/assets/4147381/3fb9e5fb-1f98-43e2-a934-923d57e5e01f

kerem commented

2026-03-03 19:53:31 +03:00

Author

Owner

@seidnerj commented on GitHub (Jan 11, 2024):

Was going to post this as a bug because I thought it used to work how you describe wanted behaviour, but maybe it's been like this all along? Needless to say I agree that current behaviour is counter-intuitive and being able to select multiple apps and/or domains would be really nice!

it's not a bug. It's a limitation of the app.

We allow multiple selections, so we can delete many domains/apps easily. However, it doesn't combine all requests from these selected domains/apps.

It would be really useful if it does - the current behavior is confusing, you're selecting multiple things you can "act" on but in the requests view you are shown only requests relevant to one of the domains you selected and its not even clear to which domain these requests belong since the shown requests depends on the last click domain and so you essentially have a situation where the same domains are selected but different requests are shown see an example here:

@seidnerj commented on GitHub (Jan 11, 2024): > > Was going to post this as a bug because I thought it used to work how you describe wanted behaviour, but maybe it's been like this all along? Needless to say I agree that current behaviour is counter-intuitive and being able to select multiple apps and/or domains would be really nice! > > it's not a bug. It's a limitation of the app. > > We allow multiple selections, so we can delete many domains/apps easily. However, it doesn't combine all requests from these selected domains/apps. It would be really useful if it does - the current behavior is confusing, you're selecting multiple things you can "act" on but in the requests view you are shown only requests relevant to one of the domains you selected and its not even clear to which domain these requests belong since the shown requests depends on the last click domain and so you essentially have a situation where the same domains are selected but different requests are shown see an example here: <img width="866" alt="Screenshot 2024-01-11 at 11 56 32" src="https://github.com/ProxymanApp/Proxyman/assets/4147381/efe066a7-face-49f3-914b-fb6aa4f209ef"> <img width="871" alt="Screenshot 2024-01-11 at 11 56 29" src="https://github.com/ProxymanApp/Proxyman/assets/4147381/2a1e0e1b-070d-43c7-b1ba-524f03ed5a60">

kerem commented

2026-03-03 19:53:31 +03:00

Author

Owner

@NghiaTranUIT commented on GitHub (Jan 12, 2024):

This combined with selection remaining when deleting a bunch of requests is definitely the top 2 most annoying things using Proxyman which is otherwise an amazing product.

@seidnerj can you share with me the video or screenshot to show it ?
Currently, after deleting a list of selected requests in the main table -> The Selection is remained is correct behavior from macOS.
I'm not sure what you expect: Reset the index to 0 🤔

Attached a video below. The scenario is you select a bunch of requests, then delete them, but after the deletion the selection persists and now other requests are selected. This might make sense when you only selected a single request, the selection just moves to the next one that's available but when there are multiple requests - its confusing because you are now selecting a bunch of random requests. After deletion I would expect the selection to behave as follows:

For a single request, move the selection to the next available request, if such exists.

For multiple consecutive requests - move to the next available request, that's after the last selected request.

For multiple non-consecutive requests - eliminate all selection, no rows will be selected after the deletion.

Makes sense?

Screen.Recording.2024-01-11.at.11.34.32-720.mov

Thanks for the video. It makes sense now. I'm going to fix this 👍

@NghiaTranUIT commented on GitHub (Jan 12, 2024): > > > This combined with selection remaining when deleting a bunch of requests is definitely the top 2 most annoying things using Proxyman which is otherwise an amazing product. > > > > > > @seidnerj can you share with me the video or screenshot to show it ? > > Currently, after deleting a list of selected requests in the main table -> The Selection is remained is correct behavior from macOS. > > I'm not sure what you expect: Reset the index to 0 🤔 > > Attached a video below. The scenario is you select a bunch of requests, then delete them, but after the deletion the selection persists and now other requests are selected. This might make sense when you only selected a single request, the selection just moves to the next one that's available but when there are multiple requests - its confusing because you are now selecting a bunch of random requests. After deletion I would expect the selection to behave as follows: > > 1. For a single request, move the selection to the next available request, if such exists. > 2. For multiple consecutive requests - move to the next available request, that's after the last selected request. > 3. For multiple non-consecutive requests - eliminate all selection, no rows will be selected after the deletion. > > Makes sense? > > Screen.Recording.2024-01-11.at.11.34.32-720.mov Thanks for the video. It makes sense now. I'm going to fix this 👍

kerem commented

2026-03-03 19:53:31 +03:00

Author

Owner

@NghiaTranUIT commented on GitHub (Jan 12, 2024):

Was going to post this as a bug because I thought it used to work how you describe wanted behaviour, but maybe it's been like this all along? Needless to say I agree that current behaviour is counter-intuitive and being able to select multiple apps and/or domains would be really nice!

it's not a bug. It's a limitation of the app.
We allow multiple selections, so we can delete many domains/apps easily. However, it doesn't combine all requests from these selected domains/apps.

It would be really useful if it does - the current behavior is confusing, you're selecting multiple things you can "act" on but in the requests view you are shown only requests relevant to one of the domains you selected and its not even clear to which domain these requests belong since the shown requests depends on the last click domain and so you essentially have a situation where the same domains are selected but different requests are shown see an example here:

It's a known issue unfortunately, it's how we design the TreeNode. It doesn't enable to showing of multiple requests/responses when selecting multiple apps/domains.

@NghiaTranUIT commented on GitHub (Jan 12, 2024): > > > Was going to post this as a bug because I thought it used to work how you describe wanted behaviour, but maybe it's been like this all along? Needless to say I agree that current behaviour is counter-intuitive and being able to select multiple apps and/or domains would be really nice! > > > > > > it's not a bug. It's a limitation of the app. > > We allow multiple selections, so we can delete many domains/apps easily. However, it doesn't combine all requests from these selected domains/apps. > > It would be really useful if it does - the current behavior is confusing, you're selecting multiple things you can "act" on but in the requests view you are shown only requests relevant to one of the domains you selected and its not even clear to which domain these requests belong since the shown requests depends on the last click domain and so you essentially have a situation where the same domains are selected but different requests are shown see an example here: > > <img alt="Screenshot 2024-01-11 at 11 56 32" width="866" src="https://private-user-images.githubusercontent.com/4147381/295869600-efe066a7-face-49f3-914b-fb6aa4f209ef.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MDUwMjMyODEsIm5iZiI6MTcwNTAyMjk4MSwicGF0aCI6Ii80MTQ3MzgxLzI5NTg2OTYwMC1lZmUwNjZhNy1mYWNlLTQ5ZjMtOTE0Yi1mYjZhYTRmMjA5ZWYucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDExMiUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDAxMTJUMDEyOTQxWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9MGU5MzUxODQxNTI3NmExMDFlMjljMzY1OWU4MGU5ZDA3ZWUyZmNiMWFhZDE5ZGJiZDg5MmFkZTY4MmQxZTM5MiZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.qxFXPeYsiSlNBNCGOCpcK4LMovngjrPwcBsWciqHOwY"> <img alt="Screenshot 2024-01-11 at 11 56 29" width="871" src="https://private-user-images.githubusercontent.com/4147381/295869612-2a1e0e1b-070d-43c7-b1ba-524f03ed5a60.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MDUwMjMyODEsIm5iZiI6MTcwNTAyMjk4MSwicGF0aCI6Ii80MTQ3MzgxLzI5NTg2OTYxMi0yYTFlMGUxYi0wNzBkLTQzYzctYjFiYS01MjRmMDNlZDVhNjAucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDExMiUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDAxMTJUMDEyOTQxWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9ZWRhMDQyYjU5YjZjMGFmOTg4NDZlZGEyMmE1NmM2ZTg3YTJiNmMxYmYwOWQ3NjdmZDhkMzljZjhkYmM1ZjU2ZSZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.LaGigg2q0ptgn7TQnI50WPIiKyGAY1hE6QXZgwew0SA"> It's a known issue unfortunately, it's how we design the TreeNode. It doesn't enable to showing of multiple requests/responses when selecting multiple apps/domains.

kerem commented

2026-03-03 19:53:31 +03:00

Author

Owner

@seidnerj commented on GitHub (Jan 12, 2024):

This combined with selection remaining when deleting a bunch of requests is definitely the top 2 most annoying things using Proxyman which is otherwise an amazing product.

@seidnerj can you share with me the video or screenshot to show it ?

Currently, after deleting a list of selected requests in the main table -> The Selection is remained is correct behavior from macOS.

I'm not sure what you expect: Reset the index to 0 🤔

Attached a video below. The scenario is you select a bunch of requests, then delete them, but after the deletion the selection persists and now other requests are selected. This might make sense when you only selected a single request, the selection just moves to the next one that's available but when there are multiple requests - its confusing because you are now selecting a bunch of random requests. After deletion I would expect the selection to behave as follows:

For a single request, move the selection to the next available request, if such exists.

For multiple consecutive requests - move to the next available request, that's after the last selected request.

For multiple non-consecutive requests - eliminate all selection, no rows will be selected after the deletion.

Makes sense?

Screen.Recording.2024-01-11.at.11.34.32-720.mov

Thanks for the video. It makes sense now. I'm going to fix this 👍

Thanks a lot!

@seidnerj commented on GitHub (Jan 12, 2024): > > > > This combined with selection remaining when deleting a bunch of requests is definitely the top 2 most annoying things using Proxyman which is otherwise an amazing product. > > > > > > > > > > > > @seidnerj can you share with me the video or screenshot to show it ? > > > > Currently, after deleting a list of selected requests in the main table -> The Selection is remained is correct behavior from macOS. > > > > I'm not sure what you expect: Reset the index to 0 🤔 > > > > > > Attached a video below. The scenario is you select a bunch of requests, then delete them, but after the deletion the selection persists and now other requests are selected. This might make sense when you only selected a single request, the selection just moves to the next one that's available but when there are multiple requests - its confusing because you are now selecting a bunch of random requests. After deletion I would expect the selection to behave as follows: > > > > > > 1. For a single request, move the selection to the next available request, if such exists. > > > 2. For multiple consecutive requests - move to the next available request, that's after the last selected request. > > > 3. For multiple non-consecutive requests - eliminate all selection, no rows will be selected after the deletion. > > > > > > Makes sense? > > > > > > Screen.Recording.2024-01-11.at.11.34.32-720.mov > > > > Thanks for the video. It makes sense now. I'm going to fix this 👍 Thanks a lot!

kerem commented

2026-03-03 19:53:31 +03:00

Author

Owner

@NghiaTranUIT commented on GitHub (Jan 12, 2024):

@seidnerj the selection after deleting issue is fixed now. You can use this Beta build: https://download.proxyman.io/beta/Proxyman_4.16.0_Fix_selection_after_deleting.dmg

Video

https://github.com/ProxymanApp/Proxyman/assets/5878421/05a5995c-8394-4ce7-a437-ed9771a4bacd

https://github.com/ProxymanApp/Proxyman/assets/5878421/2595f411-9124-4927-844f-f607c107d1b0

Please share with me your thought. I'm trying to mimic the same UX behavior of the Finder app.

@NghiaTranUIT commented on GitHub (Jan 12, 2024): @seidnerj the selection after deleting issue is fixed now. You can use this Beta build: https://download.proxyman.io/beta/Proxyman_4.16.0_Fix_selection_after_deleting.dmg ## Video https://github.com/ProxymanApp/Proxyman/assets/5878421/05a5995c-8394-4ce7-a437-ed9771a4bacd https://github.com/ProxymanApp/Proxyman/assets/5878421/2595f411-9124-4927-844f-f607c107d1b0 --------- Please share with me your thought. I'm trying to mimic the same UX behavior of the Finder app.

kerem commented

2026-03-03 19:53:31 +03:00

Author

Owner

@seidnerj commented on GitHub (Jan 12, 2024):

@NghiaTranUIT That's awesome!

In the case of non-consecutive requests, after deletion, the selection should be of the next available request after the last deleted request (not the first request, as is shown in the video you attached).

Also, note that if there if there no requests available appearing after the last deleted request then after deletion no request should be selected. This is consistent with the finder app (see attached video exhibiting this behavior).

https://github.com/ProxymanApp/Proxyman/assets/4147381/7752d1b7-527e-40df-bf02-a87733319bc4

@seidnerj commented on GitHub (Jan 12, 2024): @NghiaTranUIT That's awesome! In the case of non-consecutive requests, after deletion, the selection should be of the next available request after the **last deleted** request (not the first request, as is shown in the video you attached). Also, note that if there if there no requests available appearing after the last deleted request then after deletion no request should be selected. This is consistent with the finder app (see attached video exhibiting this behavior). https://github.com/ProxymanApp/Proxyman/assets/4147381/7752d1b7-527e-40df-bf02-a87733319bc4

kerem commented

2026-03-03 19:53:31 +03:00

Author

Owner

@NghiaTranUIT commented on GitHub (Jan 12, 2024):

Also, note that if there if there no requests available appearing after the last deleted request then after deletion no request should be selected. This is consistent with the finder app (see attached video exhibiting this behavior).

It's tedious to re-select (click) again to see the request-response.

I'm happy with the current change. It automatically selects the last row, so I can see the Request/Response immediately. No need to click again to see it.

@NghiaTranUIT commented on GitHub (Jan 12, 2024): > Also, note that if there if there no requests available appearing after the last deleted request then after deletion no request should be selected. This is consistent with the finder app (see attached video exhibiting this behavior). It's tedious to re-select (click) again to see the request-response. I'm happy with the current change. It automatically selects the last row, so I can see the Request/Response immediately. No need to click again to see it.

kerem commented

2026-03-03 19:53:31 +03:00

Author

Owner

@seidnerj commented on GitHub (Jan 12, 2024):

Sorry, I'm a bit confused - in the video you sent (1st video, second 9), it can be seen that after the deleting requests 2, 25 & 28 request 15 becomes selected, i.e. the first row, not the last row (which would be request 29 in this case)?

In general, I think an app should strive for "behavior" which is consistent with an end-user's expectation. I such a case, I believe the expectation is that it behaves the way other apps behave (e.g. Finder app etc.).

@seidnerj commented on GitHub (Jan 12, 2024): Sorry, I'm a bit confused - in the video you sent (1st video, second 9), it can be seen that after the deleting requests 2, 25 & 28 request 15 becomes selected, i.e. the first row, not the last row (which would be request 29 in this case)? In general, I think an app should strive for "behavior" which is consistent with an end-user's expectation. I such a case, I believe the expectation is that it behaves the way other apps behave (e.g. Finder app etc.).

Rows
Columns

[GH-ISSUE #1697] Selection of multiple Apps and/or Domains should apply appropriate filtering to the requests view #1688

Description

Why this feature/change is important?

Video