Aglet

How to verify a browser long-task freeze fix safely in practice

Verification must show that the blocked interaction responds sooner without hiding work or changing its meaning. Replay the same input with matched data and device conditions, inspect main-thread intervals, and exercise cancellation and nearby controls. Include a smaller case so an optimization does not regress the normal path.

Check whether the outcome improved

  1. Replay the original freeze conditions

    Use the same route, input sequence, dataset shape, viewport, and device class from the baseline. Record input dispatch, handler completion, first responsive frame, final content, and any errors. Compare more than total duration because a gap before visible feedback may still feel frozen.

  2. Check work distribution and result integrity

    Inspect whether long tasks were shortened, split, or merely moved after the interaction. Confirm that filtering, sorting, selection, focus, and displayed counts match the baseline. Exercise cancellation or navigation during work and record whether the screen recovers without stale or partial state.

  3. Probe nearby controls and larger data

    Repeat a related interaction and increase the dataset within a realistic range. Watch for new layout churn, delayed keyboard input, dropped loading feedback, or a second long task after the first result. Compare the smallest and largest tested cases to expose a tradeoff.

What to carry forward

Classify the result as verified, regressed, unchanged, or inconclusive with the original conditions and evidence attached. A fix passes only when the first response is usable, final results remain correct, cancellation still works, and nearby interactions do not inherit the freeze.

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