Title: [174037] trunk/Source
- Revision
- 174037
- Author
- b...@cs.washington.edu
- Date
- 2014-09-27 15:17:29 -0700 (Sat, 27 Sep 2014)
Log Message
Web Replay: Playback position updates should be sent before the next event loop input is dispatched
https://bugs.webkit.org/show_bug.cgi?id=137162
Reviewed by Timothy Hatcher.
Source/WebCore:
To drive playback position updates in the Inspector UI, we send playbackHitPosition protocol
messages as the replay backend dispatches inputs. However, right now the semantics of that
message are muddy. The update is sent *after* the input at the offset is dispatched. This leads
to unexpected results if the debugger pauses while the input is being dispatched: the frontend
will only know about the previous (stale) playback position when the debugger pauses.
With this patch, the backend sends the playbackHitPosition(segmentOffset=n, inputOffset=m)
message when backend is about to dispatch input m, but has not yet begun to do so. Thus, any
subsequent page execution events (profiling, debugger pauses, etc) until the next
playbackHitPosition are caused by input m's being dispatched.
* inspector/protocol/Replay.json: Clarify the message's semantics.
* replay/ReplayController.cpp:
(WebCore::ReplayController::willDispatchInput):
(WebCore::ReplayController::didDispatchInput):
Source/WebInspectorUI:
Pausing playback from the UI was broken because of a typo. Fix this, and rename
stopPlayback to cancelPlayback.
* UserInterface/Controllers/ReplayManager.js:
(WebInspector.ReplayManager.prototype.switchSession.if):
Modified Paths
Diff
Modified: trunk/Source/WebCore/ChangeLog (174036 => 174037)
--- trunk/Source/WebCore/ChangeLog 2014-09-27 20:27:59 UTC (rev 174036)
+++ trunk/Source/WebCore/ChangeLog 2014-09-27 22:17:29 UTC (rev 174037)
@@ -1,3 +1,26 @@
+2014-09-27 Brian J. Burg <b...@cs.washington.edu>
+
+ Web Replay: Playback position updates should be sent before the next event loop input is dispatched
+ https://bugs.webkit.org/show_bug.cgi?id=137162
+
+ Reviewed by Timothy Hatcher.
+
+ To drive playback position updates in the Inspector UI, we send playbackHitPosition protocol
+ messages as the replay backend dispatches inputs. However, right now the semantics of that
+ message are muddy. The update is sent *after* the input at the offset is dispatched. This leads
+ to unexpected results if the debugger pauses while the input is being dispatched: the frontend
+ will only know about the previous (stale) playback position when the debugger pauses.
+
+ With this patch, the backend sends the playbackHitPosition(segmentOffset=n, inputOffset=m)
+ message when backend is about to dispatch input m, but has not yet begun to do so. Thus, any
+ subsequent page execution events (profiling, debugger pauses, etc) until the next
+ playbackHitPosition are caused by input m's being dispatched.
+
+ * inspector/protocol/Replay.json: Clarify the message's semantics.
+ * replay/ReplayController.cpp:
+ (WebCore::ReplayController::willDispatchInput):
+ (WebCore::ReplayController::didDispatchInput):
+
2014-09-27 Benjamin Poulain <bpoul...@apple.com>
Chaining multiple :nth-child() does not work properly
Modified: trunk/Source/WebCore/inspector/protocol/Replay.json (174036 => 174037)
--- trunk/Source/WebCore/inspector/protocol/Replay.json 2014-09-27 20:27:59 UTC (rev 174036)
+++ trunk/Source/WebCore/inspector/protocol/Replay.json 2014-09-27 22:17:29 UTC (rev 174037)
@@ -171,7 +171,7 @@
},
{
"name": "playbackHitPosition",
- "description": "A position was reached during playback of the session.",
+ "description": "Playback within the session has progressed up to this position, and is about to replay the input at the specified offset.",
"parameters": [
{ "name": "position", "$ref": "ReplayPosition", "description": "The playback position that was hit." },
{ "name": "timestamp", "type": "number", "description": "A timestamp for the event." }
Modified: trunk/Source/WebCore/replay/ReplayController.cpp (174036 => 174037)
--- trunk/Source/WebCore/replay/ReplayController.cpp 2014-09-27 20:27:59 UTC (rev 174036)
+++ trunk/Source/WebCore/replay/ReplayController.cpp 2014-09-27 22:17:29 UTC (rev 174037)
@@ -510,6 +510,9 @@
ASSERT(m_segmentState == SegmentState::Dispatching);
m_currentPosition.inputOffset++;
+
+ InspectorInstrumentation::playbackHitPosition(&m_page, m_currentPosition);
+
if (m_currentPosition == m_targetPosition)
pausePlayback();
}
@@ -518,8 +521,6 @@
{
ASSERT(m_sessionState == SessionState::Replaying);
ASSERT(m_segmentState == SegmentState::Dispatching);
-
- InspectorInstrumentation::playbackHitPosition(&m_page, m_currentPosition);
}
void ReplayController::didDispatchFinalInput()
Modified: trunk/Source/WebInspectorUI/ChangeLog (174036 => 174037)
--- trunk/Source/WebInspectorUI/ChangeLog 2014-09-27 20:27:59 UTC (rev 174036)
+++ trunk/Source/WebInspectorUI/ChangeLog 2014-09-27 22:17:29 UTC (rev 174037)
@@ -1,3 +1,16 @@
+2014-09-27 Brian J. Burg <b...@cs.washington.edu>
+
+ Web Replay: Playback position updates should be sent before the next event loop input is dispatched
+ https://bugs.webkit.org/show_bug.cgi?id=137162
+
+ Reviewed by Timothy Hatcher.
+
+ Pausing playback from the UI was broken because of a typo. Fix this, and rename
+ stopPlayback to cancelPlayback.
+
+ * UserInterface/Controllers/ReplayManager.js:
+ (WebInspector.ReplayManager.prototype.switchSession.if):
+
2014-09-26 Joseph Pecoraro <pecor...@apple.com>
Web Inspector: Automatic Inspection should continue once all breakpoints are loaded
Modified: trunk/Source/WebInspectorUI/UserInterface/Controllers/ReplayManager.js (174036 => 174037)
--- trunk/Source/WebInspectorUI/UserInterface/Controllers/ReplayManager.js 2014-09-27 20:27:59 UTC (rev 174036)
+++ trunk/Source/WebInspectorUI/UserInterface/Controllers/ReplayManager.js 2014-09-27 22:17:29 UTC (rev 174037)
@@ -213,7 +213,7 @@
if (this.sessionState === WebInspector.ReplayManager.SessionState.Replaying) {
result = result.then(function() {
- return WebInspector.replayManager.stopPlayback();
+ return WebInspector.replayManager.cancelPlayback();
});
}
@@ -244,7 +244,7 @@
if (this.sessionState === WebInspector.ReplayManager.SessionState.Replaying) {
result = result.then(function() {
- return WebInspector.replayManager.stopPlayback();
+ return WebInspector.replayManager.cancelPlayback();
});
}
@@ -289,7 +289,7 @@
if (this.sessionState === WebInspector.ReplayManager.SessionState.Inactive)
return result; // Already stopped.
- if (this.sessionState !== WebInspector.ReplayManager.SegmentState.Dispatching)
+ if (this.segmentState !== WebInspector.ReplayManager.SegmentState.Dispatching)
return result; // Already stopped.
result = result.then(function() {
@@ -307,7 +307,7 @@
// Pause playback and unload the current session segment as soon as possible.
// Returns a promise that resolves when the current segment is unloaded.
- stopPlayback: function() // --> ()
+ cancelPlayback: function() // --> ()
{
console.assert(this.sessionState !== WebInspector.ReplayManager.SessionState.Capturing, "Cannot stop playback while capturing.");
@@ -321,7 +321,7 @@
console.assert(manager.sessionState === WebInspector.ReplayManager.SessionState.Replaying);
console.assert(manager.segmentState !== WebInspector.ReplayManager.SegmentState.Appending);
- return ReplayAgent.stopPlayback();
+ return ReplayAgent.cancelPlayback();
}).catch(function(error) {
console.error("Failed to stop playback: ", error);
throw error;
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
