Closed
Bug 1504909
Opened 6 years ago
Closed 6 years ago
Include current execution point and recording endpoint in pause packets
Categories
(Core Graveyard :: Web Replay, defect)
Core Graveyard
Web Replay
Tracking
(firefox65 fixed)
RESOLVED
FIXED
mozilla65
Tracking | Status | |
---|---|---|
firefox65 | --- | fixed |
People
(Reporter: bhackett1024, Assigned: bhackett1024)
References
Details
Attachments
(5 files)
19.46 KB,
patch
|
Details | Diff | Splinter Review | |
2.28 KB,
patch
|
loganfsmyth
:
review+
|
Details | Diff | Splinter Review |
2.88 KB,
patch
|
loganfsmyth
:
review+
|
Details | Diff | Splinter Review |
6.22 KB,
patch
|
loganfsmyth
:
review+
|
Details | Diff | Splinter Review |
7.97 KB,
patch
|
loganfsmyth
:
review+
|
Details | Diff | Splinter Review |
When a thread actor pauses it includes an execution point for where it is paused at, but this reflects the last console message instead of where the thread currently is. The attached patch changes this so that the exact location of the pause is included in this packet. The recording endpoint is also specified in the packet, which the devtools client can use for setting the scale of the timeline.
Assignee | ||
Comment 1•6 years ago
|
||
Changes to the debugger server and replaying process JS to include the current point and recording endpoint in paused packets.
Attachment #9022813 -
Flags: review?(lsmyth)
Assignee | ||
Comment 2•6 years ago
|
||
Remove the now-unused interface to get the recording position as a fraction in the [0,1] range.
Attachment #9022814 -
Flags: review?(lsmyth)
Assignee | ||
Comment 3•6 years ago
|
||
Information about the bounds of the recording and the current position within the recording is stored by the navigation state in toolkit/recordreplay/ipc/ChildNavigation.cpp. This patch extends some existing interfaces in this code so that the JS bindings can access this information.
Attachment #9022815 -
Flags: review?(lsmyth)
Assignee | ||
Comment 4•6 years ago
|
||
Currently, ExecutionPoint does not specify a progress counter for points which coincide with checkpoints. This isn't very useful for easily determining where a given ExecutionPoint should go on the timeline. This patch simplifies things for the devtools JS by just always including the progress counter in an ExecutionPoint.
Attachment #9022816 -
Flags: review?(lsmyth)
Updated•6 years ago
|
Attachment #9022813 -
Flags: review?(lsmyth) → review+
Updated•6 years ago
|
Attachment #9022814 -
Flags: review?(lsmyth) → review+
Updated•6 years ago
|
Attachment #9022815 -
Flags: review?(lsmyth) → review+
Updated•6 years ago
|
Attachment #9022816 -
Flags: review?(lsmyth) → review+
Pushed by bhackett@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/42475558ccac Part 1 - Include current point and endpoint in paused packets, r=lsmyth. https://hg.mozilla.org/integration/mozilla-inbound/rev/669dca3ed43c Part 2 - Remove unused recordingPosition interface, r=lsmyth. https://hg.mozilla.org/integration/mozilla-inbound/rev/8f33aed589e1 Part 3 - Get the current point and recording endpoint from navigation state, r=lsmyth. https://hg.mozilla.org/integration/mozilla-inbound/rev/aec161975269 Part 4 - Always store progress counter in execution points, r=lsmyth.
Comment 6•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/42475558ccac https://hg.mozilla.org/mozilla-central/rev/669dca3ed43c https://hg.mozilla.org/mozilla-central/rev/8f33aed589e1 https://hg.mozilla.org/mozilla-central/rev/aec161975269
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox65:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
Updated•4 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•