i am working on this.

hey @david-allison
When reproducing the issue, I observed:

During long press, the grid scales up

• If an entry's center was at position (x,y) before resize, it moves to (xscale, yscale) after

• This naturally shifts the selected item away from the user's finger position

This shift is expected because:

• The grid is maintaining relative positions of all entries while scaling
• The scaling transformation inherently moves points away from their original positions

We could set the initial grid size in browser view to match the post-long-press grid size. This would eliminate the scaling transition and keep selected items aligned with touch points.

• This issue was introduced in feat(browser): render rows using backend #16620

We could set the initial grid size in browser view to match the post-long-press grid size. This would eliminate the scaling transition and keep selected items aligned with touch points.

What does this mean? Making the items larger when the checkbox doesn't appear?

Not for now, we have a lot of information which we want to display, and we want the grid as vertically compact as possible.

If you try 2.20.1, this functionality works as expected, and we should maintain the same functionality.

• This issue was introduced in feat(browser): render rows using backend #16620

We could set the initial grid size in browser view to match the post-long-press grid size. This would eliminate the scaling transition and keep selected items aligned with touch points.

What does this mean? Making the items larger when the checkbox doesn't appear?

Not for now, we have a lot of information which we want to display, and we want the grid as vertically compact as possible.

If you try 2.20.1, this functionality works as expected, and we should maintain the same functionality.

okay could you clarify me what are the exact steps to reproduce the bug and what is expected ,
from what i have understood is longPressing the row in Card Browser makes checkbox view visible and shifts the selected row away from user's fingertip , am i right ?

What does this mean? Making the items larger when the checkbox doesn't appear?

no it means to make sure upon selecting the row , the selected row doesn't shift from the position , we need to make the height of each cell in multiselect(or checkbox) view same as it was in normal recyclerview, i hope i make sense

That breaks accessibility. Checkboxes have a minimum required height

That breaks accessibility. Checkboxes have a minimum required height

you are right , but then we have to do the opposite of it , making the normal view's cell height bigger. I am just discussing possible fixes.

If you try 2.20.1, this functionality works as expected, and we should maintain the same functionality.

i tried with 2.20.1 and 2.21alpha5-debug both are working exacltly same

• 2.20.1
  https://github.com/user-attachments/assets/3aea5ccc-5891-4b52-a7f8-ed13658e67cc

• 2.21alpha5
  https://github.com/user-attachments/assets/05ca62b4-ab3a-48c8-a66e-754bdb20b5e2

@Scapesfear when there are not enough items to scroll, there's not much we can do, the items will expand to fill screen up to scroll. Try a deck with at least three screenfulls of cards and scroll to somewhere in the middle. Then test a long-press to switch into multi-select on an item in the middle of that second screen. What happens on 2.20.1 vs 2.21alpha5?

Bonus, once you have more than 6 cards in your entire collection, you may have a chance at reproducing the crash-on-card edit using boundary condition scenarios as I mentioned.

okay i will do it and tell the results

i tested with 30cards and yes the 2.21alpha5 is not working as expected