Aglet

Investigate repeated preview memory retention

Investigation should compare memory and resource state before selection, after rendering, after removal, and after the interface settles. Use repeated cycles with controlled files, then inspect which resources persist. The result should distinguish a genuine retention path from normal decode and cache behavior.

Build a useful investigation brief

  1. Choose controlled preview cycles

    Run alternating small and large files through select, render, remove, and replace operations. Record cycle count, visible items, dimensions, and settled memory after each cycle. Include a full page exit as a release comparison.

  2. Trace resource ownership

    List object URLs, decoded image surfaces, canvas buffers, worker tasks, event listeners, and references associated with each preview. For every item removed, mark whether its resources are released, reused by design, or still reachable without a visible owner.

  3. Locate the retention boundary

    Compare the first cycle where retained resources grow with the lifecycle event immediately before it. Reproduce after reordering or validation errors, and state competing explanations when tooling shows memory but not the owning reference.

What to carry forward

The investigation is sufficient when a controlled sequence identifies a resource or lifecycle boundary that persists beyond removal. If only aggregate memory is observable, report the growth pattern and release comparison without asserting which object owns it.

Technical background: MDN reference.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow