1547092 - Instant Logpoint Hits

Status: RESOLVED DUPLICATE of bug 1556813

(Core Graveyard :: Web Replay, task)

Description

[Brian Hackett [Laid off!]]

Dealing with logpoint UX responsively is trickier than with other debugger features, as displaying a logpoint requires doing evaluations at potentially many arbitrary program location. I think it would be good to break this problem up in two. If we did an up front analysis to index the execution points at which every program location is reached, then when the user adds a logpoint we will immediately know all the execution points corresponding to that logpoint. The timeline can be updated immediately, and the console can be updated immediately with placeholder 'Loading...' or something messages in place of the logpoint's evaluation result. We will then dispatch a bunch of replaying child processes to each of those execution points to perform the evaluation and fill in the message with its final value (and generate the data needed to instantly warp there). This should happen pretty quickly, though it depends on the number of processes dispatched, how many execution points are associated with the logpoint, and the spacing of those execution points.

Comment 1

[Brian Hackett [Laid off!]]

Attachment: patch

This follows the strategy laid out in comment 0. When a logpoint is added, as soon as a section of the recording is scanned the hits on the logpoint are put on the timeline, with a 'Loading...' message in the console until a replaying process has gone to that point, done the evaluation, and saved pause data so that the message can be instantly warped to. This patch also makes a UI modification similar to bug 1557880: when a logpoint message has not been evaluated, or when a normal console message has not had its pause data captured, that message is partially faded out in the timeline. This makes it pretty easy to see how quickly the pause data for messages is being captured (rather slowly right now, this area needs tuning).

Comment 2

[Brian Hackett [Laid off!]]

I'm folding this into bug 1556813.