Multi-select is broken on the Containers table

Actual Behavior

Rows on the Containers page cannot be multi-selected the way they used to be.

Shift-clicking a container name does nothing at all: no range is selected, and no single row is selected either. Control-clicking (Command on macOS) a row to drop it from the selection removes a different row from the selection instead of the one clicked. And whenever the container list refreshes (any container starting, stopping or being removed fires a refresh), the whole selection is cleared.

The net effect is that acting on several containers at once — the point of the bulk Actions button — is impractical.

Steps to Reproduce

Start five or more containers so the Containers page has several rows.

1. Click the name of the first container, then shift-click the name of the fifth.
2. Click a row (not the name), shift-click a row four below it, then control-click (Command-click on macOS) the middle row of that range.
3. Select three rows, then stop one container from a terminal (docker stop <name>) while the page is open.

Result

1. Nothing is selected. The same clicks anywhere else in the row (State, Image, Uptime) do select a range, so it is specific to the Name column — which is the column users click.
2. Five rows are selected, then the first row of the selection is deselected rather than the middle one that was clicked.
3. The selection empties as soon as the list refreshes.

Expected Behavior

1. Shift-clicking extends the selection from the previously clicked row to the clicked one, wherever in the row the click lands.
2. Control/Command-clicking toggles exactly the row clicked.
3. A refresh keeps selected the rows that are still in the table.

Additional Information

Shift-clicking the name column worked up to v1.20.x and broke in v1.21.0. In 1.21.0 the container name became a link to the new container info page (commit 3dbe60e74), and SortableTable's selection code deliberately ignores clicks that land on a link or a button, so the name column stopped taking part in selection.

The other two problems are older and live in SortableTable itself:

• selection.js's update() matches the rows to remove by _key, which is the default value of the key-field prop. The Containers table sets key-field="id", so no row has a _key and every row compares equal to every other one; the first selected row is spliced out instead of the intended one. Any table with its own key field is affected — Volumes and Images too.
• The selection is matched to the table contents by object identity. The Containers page builds its rows with merge({}, container, …), so every refresh produces new row objects and the identity check drops the whole selection — along with the anchor row a subsequent shift-click would have extended from.

A pull request follows.

Rancher Desktop Version

1.24.0

Rancher Desktop K8s Version

1.31.6

Which container engine are you using?

moby (docker cli)

What operating system are you using?

Windows

Operating System / Build Version

Windows 11 Enterprise 10.0.26200

What CPU architecture are you using?

x64

Linux only: what package format did you use to install Rancher Desktop?

N/A

Windows User Only

N/A