Problem with multi-select mode using rectangle drag to select

[mark-friedman]

Check for duplicates

• [X] I have searched for similar issues before opening a new one.

Description

When you are in multi-select mode and drag a rectangle in order to select multiple blocks, clicking on one of the selected blocks will then cause that block to get deselected. Note that using shift-clicks to select multiple blocks does not have that behavior.

Reproduction steps

Stack trace

No response

Screenshots

No response

Browsers

No response

[changminbark]

What is supposed to be the intended behavior?

[HollowMan6]

What is supposed to be the intended behavior?

"clicking on one of the selected blocks will then cause that block to get deselected" should be the expected one. Check README User behavior No.3.

Note that using shift-clicks to select multiple blocks does not have that behavior.

I don't think I can reproduce this in the main branch. What version are you currently using? I think this has already been fixed in https://github.com/mit-cml/workspace-multiselect/commit/230e9f6420537a1e51c4bd4220d12704c3aaee0c

[mark-friedman]

What is supposed to be the intended behavior?

"clicking on one of the selected blocks will then cause that block to get deselected" should be the expected one. Check README User behavior No.3.

User behavior no. 3 is about shift-click. I'm referring to a plain click after the multi-select.

Note that using shift-clicks to select multiple blocks does not have that behavior.

I don't think I can reproduce this in the main branch. What version are you currently using? I think this has already been fixed in 230e9f6

You can see the behavior at https://hollowman6.github.io/workspace-multiselect/. I verified that that commit is in the source for that link. Try, for example, to do a multi-field update on a set of blocks selected via a rectangle drag.

[HollowMan6]

I'm referring to a plain click after the multi-select.

You can see the behavior at https://hollowman6.github.io/workspace-multiselect/. I verified that that commit is in the source for that link. Try, for example, to do a multi-field update on a set of blocks selected via a rectangle drag.

Hmm, no luck for reproduction, any video/GIF for this?

[mark-friedman]

Hmm, no luck for reproduction, any video/GIF for this?

Ah, the difference is that I didn't explicitly turn off multi-select mode (i.e. didn't click the check mark) before trying the multi-field update. If you ask me, the current behavior is a bit unintuitive and suboptimal. Since we already document shift-click to unselect, why have plan click also deselecting? It would make things simpler for the end-user, I think, to not require clicking the check mark in this situation. Would it make things inconsistent somewhere else if we changed how this works?

[HollowMan6]

I'm not sure if you are referring to this one:

This is actually somewhat expected, since we are still in multi-select mode, when you click on the text input field, the click event first de-select the block, then the edit cause us to exit the multi-select mode automatically.

If you ask me, the current behavior is a bit unintuitive and suboptimal. Since we already document shift-click to unselect, why have plan click also deselecting?

Then how should we allow users to deselect the already selected block one by one, instead of deselect everything all together?

It would make things simpler for the end-user, I think, to not require clicking the check mark in this situation. Would it make things inconsistent somewhere else if we changed how this works?

I'm not quite sure about what to change. The check-mark is optional if you are using keyboard, you just use the shift key and you don't need to care about the check-mark icon, we will be in multi-select mode when you keep holding the shift key. That check mark icon was designed to facilitate end-devices which don't have an actual keyboard (e.g. mobile phones) https://github.com/mit-cml/workspace-multiselect?tab=readme-ov-file#user-behavior See No.6 here. For mobile devices, that's unfortunately needed for them to exit multi-select mode manually by clicking on the icon.

[HollowMan6]

the click event first de-select the block, then the edit cause us to exit the multi-select mode automatically.

Although it might be possible for us to ignore the de-select here, it's more about the order of event to handle, I'll check.

[mark-friedman]

I'm not sure if you are referring to this one:

This is actually somewhat expected, since we are still in multi-select mode, when you click on the text input field, the click event first deselect the block, then the edit cause us to exit the multi-select mode automatically.

Yes, I'm questioning whether the click should de-select the block, since we already have (documented) shift-click to de-select the block.

If you ask me, the current behavior is a bit unintuitive and suboptimal. Since we already document shift-click to unselect, why have plan click also deselecting?

Then how should we allow users to deselect the already selected block one by one, instead of deselect everything all together?

Shift-click, which is what the documentation says is the way to deselect.

It would make things simpler for the end-user, I think, to not require clicking the check mark in this situation. Would it make things inconsistent somewhere else if we changed how this works?

I'm not quite sure about what to change. The check-mark is optional if you are using keyboard, you just use the shift key and you don't need to care about the check-mark icon, we will be in multi-select mode when you keep holding the shift key. That check mark icon was designed to facilitate end-devices which don't have an actual keyboard (e.g. mobile phones) https://github.com/mit-cml/workspace-multiselect?tab=readme-ov-file#user-behavior See No.6 here. For mobile devices, that's unfortunately needed for them to exit multi-select mode manually by clicking on the icon.

Ha, I didn't even realize that the check-mark is optional and that you can shift-click-drag to multi-select! That seems to work as I expected.

[mark-friedman]

the click event first de-select the block, then the edit cause us to exit the multi-select mode automatically.

Although it might be possible for us to ignore the de-select here, it's more about the order of event to handle, I'll check.

I think it's worth doing, if it's not too difficult.

[HollowMan6]

Although it might be possible for us to ignore the de-select here, it's more about the order of event to handle, I'll check.

I think it's worth doing, if it's not too difficult.

Unfortunately, it's not that simple, since the click event is handled on the DragSelect library's side and we have no direct control over that, so I use a white list for the common field element, and revert the last unselected block if we have any: https://github.com/mit-cml/workspace-multiselect/commit/396f88ba1a97880624a1bc08e4965181d8a2fb86 If you need to extend that whitelist, feel free to add more there.

Shift-click, which is what the documentation says is the way to deselect.

Actually, we just have multi-select mode on when we hold the Shift, all the clicks that happen when multi-select mode is on will be treated as deselect, there's no separate distinction between shift-click or plain click. That's why I said "Clicking on the button above the dustbin is equivalent to holding/releasing the SHIFT key"

[mark-friedman]

396f88b

Thanks!

[mark-friedman]

Shift-click, which is what the documentation says is the way to deselect.

Actually, we just have multi-select mode on when we hold the Shift, all the clicks that happen when multi-select mode is on will be treated as deselect, there's no separate distinction between shift-click or plain click. That's why I said "Clicking on the button above the dustbin is equivalent to holding/releasing the SHIFT key"

Okay, I get it now. We could probably make that a little clearer in the docs. If I didn't understand it then there are probably others who won't get it either. In any case, that's something for another day ;-)

[HollowMan6]

Okay, I get it now. We could probably make that a little clearer in the docs. If I didn't understand it then there are probably others who won't get it either. In any case, that's something for another day ;-)

That would of course be appreciated! those entries were written initially when I was brainstorming for the design of this plugin in 2022, so it's not that well-organized https://github.com/mit-cml/workspace-multiselect/pull/1#issue-1301519378 We definitely need to improve that later.