Skip to content

Library: keep Delete targets clear when search hides selected items #441

Open

Description

@SashaMIT

A person should know which Library items Delete will affect after changing a search filter.

At #428 head a2c22152, search updates state.query and renders (events.js:152–155) while selectedUris survives. selectedObjects() resolves those URIs from the full folder map (selection.js:11–14). Delete uses that selection (events.js:332–338), and trashSelectedObjects() sends each selected URI to Runtime (actions.js:526–531). A selected item hidden by search can therefore remain a Delete target.

Done means:

  • Define one visible selection rule for search changes. Either remove hidden items from the active selection or make the retained targets explicit before a destructive action.
  • Cover select A, search for B, focus the results, then Delete; assert the exact URIs sent. Include mixed visible/hidden selections, zero results, clearing search and Shift+Delete.
  • Keep Keep Library navigation, uploads and rendering coherent under load #428's explicit-selection and empty-selection focus behavior. Check pointer, keyboard and menu actions against the same rule.
  • Add a real browser journey and a regression test whose reverted fix fails. Preserve Runtime capability/revision checks; selection only chooses the requested objects.

Follow-up to #428. Coordinate shared Library selection/menu work with #67; do not duplicate its wallpaper scope.

Acceptance record:

  • Candidate: see 0.8.0: Release 0.8.0 #93. Train fixes: ff233a867, a9e707648. The Library source record records review and source-gate results at 4653ab4cb662cad4ee57a32a0c904a483bfa452a and matching train patches. The historical f674 source gate supplies separate configured source evidence.
  • Installed release evidence and remaining gate: pending. Browser controls remain author-reported and the complete menu smoke retains its reported base-case failure. Prove the real browser regression/control journey and installed pointer, keyboard and menu behavior on the accepted candidate; preserve Keep Library navigation, uploads and rendering coherent under load #428's explicit-selection and empty-selection focus requirements and its Round 4 follow-up.
  • Next owner: andersalm, the current issue assignee, for current-candidate qualification and installed Library acceptance.

Activity

  1. andersalm commented on Oct 20, 2026

    @andersalm
    Contributor

    Library actions check that a target is visible when its menu or confirmation runs. The completed source review passed at 4653ab4cb662cad4ee57a32a0c904a483bfa452a; review SHA-256: cc8a7c99009dddc659ae12f91fce9ce123f69f2f2d2e2e0d9bb27c9a63f37979.
    The exact candidate passed its 1,857-second Linux source gate (log SHA-256 50de391d791120107e5c3199f5ccb50ab03689ff249ca7a3eda4b71cc096e4f3). Both Library commits have byte-identical patches on the local train as ff233a867ea63060065bcd8a1fb5ada145806868 and a9e707648327b49b89332044cf107365fdf56fe1.
    The current train f674ff63738d0e2c8724ede16bb785bef58511cb has checks and notes review in progress. Browser controls remain author-reported; the full menu smoke still has the reported base-case failure, and installed acceptance remains open.

  2. self-assigned this
    on Oct 21, 2026
  3. added this to the 0.8.0 milestone on Oct 21, 2026
  4. andersalm commented on Oct 21, 2026

    @andersalm
    Contributor

    Status (20 Oct): source fixed and reviewed: ff233a867 and a9e707648 are on the alpha.25 train (release/train-0.8.0-rc10, current head f674ff637); Codex review lib441b PASS. Remaining: installed check on signed alpha.25. Stays open until then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions