Repair a blocked screen without replacing the working application

“The page has stopped responding” describes a user's experience, not yet a cause. Before replacing an application, establish which interaction has failed and whether the owned software can support a maintainable correction. A working keyboard path and a blocked pointer path can be valuable contrasting evidence.

In this fictional supplier application, staff open a document-information drawer, close it and then try to select another request. Nothing happens when they click the request row. Reloading the page restores normal behavior until the drawer is opened again. The initial proposal is to replace the entire request screen.

Compare the same action through two routes

The reviewer uses request Q-71 and opens its information drawer D-5. After dismissal, the drawer is no longer visible. Clicking the neighboring request Q-72 produces no navigation request. However, using the keyboard to focus Q-72 and activate it does open the intended record. The server returns the expected Q-72 content.

These observations do not prove that the whole screen is sound, but they narrow this particular failure. The request route and receiving operation can work. The pointer action is not reaching the same target. Replacing the API would not address the earliest observed disagreement.

The developer inspects the element receiving the pointer at the row's position. It is the drawer's full-screen backdrop, still present above the request list. The closing animation made it transparent but did not remove it from pointer interaction. Its visual disappearance was mistaken for completion of the component's closed state.

Inspect whether the component can be repaired

The drawer is owned application code with a documented open/close lifecycle. Its supported closed state removes the backdrop from the rendered interaction layer. The existing implementation stops after changing opacity.

Three options are considered. Replacing the screen would create a much larger change without explaining why the old one failed. Permanently disabling backdrop interaction would make the closed screen usable but could break the intended open-drawer behavior. Correcting the component's transition to its supported closed state addresses the inspected cause while preserving the interaction model.

The owner chooses the lifecycle repair. The change completes dismissal by removing the backdrop and restores focus to the opener according to the agreed component behavior. It does not alter request data, permissions or the request route. The code change is reviewed with the component's actual lifecycle rather than treated as a generic rule that every transparent element should be removed.

Reproduce the failure, then challenge the repair

After the correction, the reviewer repeats Q-71 → open D-5 → close D-5 → click Q-72. The hit target is now the intended request control, one navigation request occurs and Q-72 appears. The keyboard route still reaches the same record.

The drawer is reopened. Its backdrop again performs the intended open-state function, and closing it by the supported control returns the screen to normal interaction. An unrelated filter and a different request row remain usable. Repeated open/close cycles do not accumulate invisible backdrops. These controls matter because deleting the backdrop entirely could make one test pass while damaging the component's intended open state.

The verification record contains the original sequence, the inspected hit target, the lifecycle correction and the tested interaction routes. It also identifies the browser and layout conditions examined. Other screens and devices remain outside that particular claim.

Make the replacement decision from the finding

The application is retained for this scope because the defect is localized, the component is owned and the supported repair passes the relevant controls. Replacement can still be reconsidered if later evidence reveals unavailable source rights, unmaintainable dependencies or a separate structural limitation. Age or frustration alone did not establish those conditions here.

For your own system, record the last action that works, the first action that fails and a contrasting route to the same result. Stabilisation work can use that evidence to distinguish a bounded repair from a genuine replacement requirement.