2016-09-17 03:53:29 +00:00
|
|
|
<!DOCTYPE html>
|
|
|
|
|
<html>
|
|
|
|
|
<head>
|
|
|
|
|
<script src="../../http/tests/inspector/resources/inspector-test.js"></script>
|
|
|
|
|
<script src="resources/paused-scopes.js"></script>
|
|
|
|
|
<script>
|
|
|
|
|
function test()
|
|
|
|
|
{
|
|
|
|
|
function scopeTypeName(type) {
|
|
|
|
|
switch (type) {
|
2017-08-02 03:09:57 +00:00
|
|
|
case WI.ScopeChainNode.Type.Local: return "Local";
|
|
|
|
|
case WI.ScopeChainNode.Type.Global: return "Global";
|
|
|
|
|
case WI.ScopeChainNode.Type.GlobalLexicalEnvironment: return "GlobalLexicalEnvironment";
|
|
|
|
|
case WI.ScopeChainNode.Type.With: return "With";
|
|
|
|
|
case WI.ScopeChainNode.Type.Closure: return "Closure";
|
|
|
|
|
case WI.ScopeChainNode.Type.Catch: return "Catch";
|
|
|
|
|
case WI.ScopeChainNode.Type.FunctionName: return "FunctionName";
|
|
|
|
|
case WI.ScopeChainNode.Type.Block: return "Block";
|
2016-09-17 03:53:29 +00:00
|
|
|
default: return "Unknown!";
|
|
|
|
|
};
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
function sanitizeHash(hash) {
|
|
|
|
|
return hash.replace(/:(.*?):/, ":<sourceID>:");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
function collectScopeChainProperties(scopeChain) {
|
|
|
|
|
let scopeChainData = [];
|
|
|
|
|
|
|
|
|
|
let promises = [];
|
|
|
|
|
for (let scope of scopeChain) {
|
|
|
|
|
let data = {scope, properties: []};
|
|
|
|
|
scopeChainData.push(data);
|
2017-08-02 03:09:57 +00:00
|
|
|
if (scope.type === WI.ScopeChainNode.Type.Global)
|
2016-09-17 03:53:29 +00:00
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
for (let scopeObject of scope.objects) {
|
|
|
|
|
promises.push(new Promise((resolve, reject) => {
|
2018-10-29 23:29:13 +00:00
|
|
|
scopeObject.getPropertyDescriptors((propertyDescriptors) => {
|
2016-09-17 03:53:29 +00:00
|
|
|
data.properties = data.properties.concat(propertyDescriptors);
|
|
|
|
|
resolve();
|
|
|
|
|
});
|
|
|
|
|
}));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return Promise.all(promises)
|
|
|
|
|
.then(() => scopeChainData);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
function dumpScopeChainData(scopeChainData) {
|
|
|
|
|
for (let {scope, properties} of scopeChainData) {
|
|
|
|
|
InspectorTest.log(` SCOPE: Name (${scope.name}) - Type (${scopeTypeName(scope.type)}) - Hash (${sanitizeHash(scope.hash)})`);
|
|
|
|
|
for (let propertyDescriptor of properties)
|
|
|
|
|
InspectorTest.log(` - ${propertyDescriptor.name}`);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
function dumpCallFrame(callFrame) {
|
|
|
|
|
return Promise.all([
|
|
|
|
|
collectScopeChainProperties(callFrame.scopeChain),
|
|
|
|
|
collectScopeChainProperties(callFrame.mergedScopeChain()),
|
|
|
|
|
]).then((results) => {
|
|
|
|
|
let [scopeChainData, mergedScopeChainData] = results;
|
|
|
|
|
InspectorTest.log(`CALLFRAME: ${callFrame.functionName}`);
|
|
|
|
|
InspectorTest.log("\n---- Scope Chain ----");
|
|
|
|
|
dumpScopeChainData(scopeChainData);
|
|
|
|
|
InspectorTest.log("\n---- Merged Scope Chain ----");
|
|
|
|
|
dumpScopeChainData(mergedScopeChainData);
|
|
|
|
|
InspectorTest.log("");
|
|
|
|
|
});
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
function dumpCallFrames() {
|
2017-08-02 03:09:57 +00:00
|
|
|
let targetData = WI.debuggerManager.dataForTarget(WI.debuggerManager.activeCallFrame.target);
|
Web Inspector: Include DebuggerAgent in Workers - see, pause, and step through scripts
https://bugs.webkit.org/show_bug.cgi?id=164136
<rdar://problem/29028462>
Reviewed by Brian Burg.
Source/WebCore:
Tests: inspector/worker/debugger-pause.html
inspector/worker/debugger-scripts.html
* CMakeLists.txt:
* WebCore.xcodeproj/project.pbxproj:
* inspector/InspectorAllInOne.cpp:
New file.
* inspector/PageDebuggerAgent.h:
* inspector/WorkerDebuggerAgent.cpp: Added.
(WebCore::WorkerDebuggerAgent::WorkerDebuggerAgent):
(WebCore::WorkerDebuggerAgent::~WorkerDebuggerAgent):
(WebCore::WorkerDebuggerAgent::breakpointActionLog):
(WebCore::WorkerDebuggerAgent::injectedScriptForEval):
* inspector/WorkerDebuggerAgent.h: Added.
DebuggerAgent customizations for Workers.
* inspector/WorkerInspectorController.cpp:
(WebCore::WorkerInspectorController::WorkerInspectorController):
Add the new agent.
* inspector/WorkerScriptDebugServer.cpp:
(WebCore::WorkerScriptDebugServer::runEventLoopWhilePaused):
Implement the nested run loop for Workers.
Source/WebInspectorUI:
By implementing DebuggerAgent, Workers will inform the frontend about
Scripts that evaluate in the Worker's VM and the Worker VM can pause
and send the pausing CallFrames to the frontend. This means that
WebInspector.Script and WebInspector.CallFrame will need to be made
target aware. This also means that each Target will have its own
set of debugger data, such as the list of scripts and pause data
like the pause reason / call frames. Previously all this data was
managed by DebuggerManager.
With this change we split that data out of DebuggerManager to be
per-target DebuggerData. DebuggerManager keeps `activeCallFrame`
but the list of scripts and pause data have moved into `DebuggerData`
which is per-target, accessed through DebuggerManager's new
dataForTarget(target) method.
Finally we make a few changes to the UserInterface to make Workers
and their scripts, appear grouped together. The Resources sidebar
previously had a single top level item for the Main Frame, which
has all its resources as its children (potentially grouped into
folders). With this change, each Worker gets its own top level
item as well, and the Worker's subresources (imported scripts)
become its children.
We also now associate a single mainResource with Targets. In the
case of Workers, we assume and assert that this is a Script. If
this were to ever change we would need to adjust the assumptions.
* UserInterface/Main.html:
* UserInterface/Test.html:
New files.
* UserInterface/Base/Main.js:
* UserInterface/Test/Test.js:
Add WebInspector.assumingMainTarget to fill in all the places where
we assume the main target right now, but would need to handle non-main
targets as other agents are implemented in workers. For example profile
data that assumes the main target right now could be worker targets
when we implement ScriptProfiler / Heap agents.
* UserInterface/Protocol/Connection.js:
(InspectorBackend.WorkerConnection):
* UserInterface/Protocol/Target.js:
(WebInspector.Target):
(WebInspector.Target.prototype.get DebuggerAgent):
(WebInspector.Target.prototype.get mainResource):
(WebInspector.Target.prototype.set mainResource):
(WebInspector.WorkerTarget.prototype.initialize):
(WebInspector.WorkerTarget):
Include DebuggerAgent in Targets.
Include a mainResource for Worker Targets.
* UserInterface/Protocol/DebuggerObserver.js:
(WebInspector.DebuggerObserver.prototype.scriptParsed):
(WebInspector.DebuggerObserver.prototype.breakpointResolved):
(WebInspector.DebuggerObserver.prototype.paused):
(WebInspector.DebuggerObserver.prototype.resumed):
Pass the target on to managers when necessary.
* UserInterface/Models/DebuggerData.js: Added.
(WebInspector.DebuggerData):
(WebInspector.DebuggerData.prototype.get target):
(WebInspector.DebuggerData.prototype.get callFrames):
(WebInspector.DebuggerData.prototype.get pauseReason):
(WebInspector.DebuggerData.prototype.get pauseData):
(WebInspector.DebuggerData.prototype.get scripts):
(WebInspector.DebuggerData.prototype.scriptForIdentifier):
(WebInspector.DebuggerData.prototype.scriptsForURL):
(WebInspector.DebuggerData.prototype.reset):
(WebInspector.DebuggerData.prototype.addScript):
(WebInspector.DebuggerData.prototype.pause):
(WebInspector.DebuggerData.prototype.unpause):
Extract per-target data from DebuggerManager. This includes the list
of scripts evaluated in a Target, and any pause data for this target
such as the pause reason and call frames.
* UserInterface/Controllers/DebuggerManager.js:
(WebInspector.DebuggerManager.prototype.dataForTarget):
(WebInspector.DebuggerManager.prototype.get pauseReason): Deleted.
(WebInspector.DebuggerManager.prototype.get pauseData): Deleted.
(WebInspector.DebuggerManager.prototype.get callFrames): Deleted.
(WebInspector.DebuggerManager.prototype.reset):
New way to access per-target debugger data.
(WebInspector.DebuggerManager.prototype.initializeTarget):
When a new Target is created, synchronize frontend state with the target.
Things like the list of breakpoints and global breakpoint states.
(WebInspector.DebuggerManager.prototype.scriptForIdentifier):
(WebInspector.DebuggerManager.prototype.scriptsForURL):
Convenience accessors for scripts must now provide a Target.
(WebInspector.DebuggerManager.prototype.get knownNonResourceScripts):
This is a convenience accessors for a list of all scripts across all targets
so this handles getting the list across all targets.
(WebInspector.DebuggerManager.prototype.pause):
(WebInspector.DebuggerManager.prototype.resume):
(WebInspector.DebuggerManager.prototype.stepOver):
(WebInspector.DebuggerManager.prototype.stepInto):
(WebInspector.DebuggerManager.prototype.stepOut):
(WebInspector.DebuggerManager.prototype.continueToLocation):
Stepping commands affect the current target with the active call frame.
Eventually we will change Pause and Resume behavior to affect all targets.
(WebInspector.DebuggerManager.prototype.addBreakpoint):
(WebInspector.DebuggerManager.prototype.breakpointResolved):
(WebInspector.DebuggerManager.prototype._setBreakpoint.didSetBreakpoint):
(WebInspector.DebuggerManager.prototype._setBreakpoint):
(WebInspector.DebuggerManager.prototype._removeBreakpoint):
Breakpoints should be set on all targets, but we need a way
to set them on a specific target, when initializing an
individual target when we want to inform that single target
of all of the breakpoints.
(WebInspector.DebuggerManager.prototype._breakpointDisabledStateDidChange):
(WebInspector.DebuggerManager.prototype._updateBreakOnExceptionsState):
Changing global breakpoint state should inform all targets.
(WebInspector.DebuggerManager.prototype.scriptDidParse):
Associate Scripts with a Target. Identify the main resource of a
Worker Target and set it as soon as we can.
(WebInspector.DebuggerManager.prototype.debuggerDidPause):
(WebInspector.DebuggerManager.prototype.debuggerDidResume):
(WebInspector.DebuggerManager.prototype._sourceCodeLocationFromPayload):
(WebInspector.DebuggerManager.prototype._scopeChainFromPayload):
(WebInspector.DebuggerManager.prototype._scopeChainNodeFromPayload):
(WebInspector.DebuggerManager.prototype._mainResourceDidChange):
(WebInspector.DebuggerManager.prototype._didResumeInternal):
Pausing and resuming now happens per-target, so associate
created model objects (CallFrame, ScopeChain objects) and any
other necessary data with the target.
* UserInterface/Models/Breakpoint.js:
(WebInspector.Breakpoint):
(WebInspector.Breakpoint.prototype.get target):
(WebInspector.Breakpoint.prototype.get info):
* UserInterface/Models/CallFrame.js:
(WebInspector.CallFrame):
(WebInspector.CallFrame.prototype.get target):
(WebInspector.CallFrame.fromDebuggerPayload):
(WebInspector.CallFrame.fromPayload):
* UserInterface/Models/ConsoleMessage.js:
(WebInspector.ConsoleMessage):
* UserInterface/Models/Script.js:
(WebInspector.Script):
(WebInspector.Script.prototype.get target):
(WebInspector.Script.prototype.isMainResource):
(WebInspector.Script.prototype.requestContentFromBackend):
(WebInspector.Script.prototype._resolveResource):
* UserInterface/Models/StackTrace.js:
(WebInspector.StackTrace.fromPayload):
(WebInspector.StackTrace.fromString):
* UserInterface/Models/ProbeManager.js:
(WebInspector.ProbeManager.prototype.didSampleProbe):
* UserInterface/Models/Probe.js:
(WebInspector.ProbeSample):
* UserInterface/Views/ConsoleMessageView.js:
(WebInspector.ConsoleMessageView.prototype._appendLocationLink):
(WebInspector.ConsoleMessageView.prototype._formatParameterAsString):
Associate model objects with a specific target where necessary.
* UserInterface/Views/ObjectTreeBaseTreeElement.js:
(WebInspector.ObjectTreeBaseTreeElement.prototype._appendMenusItemsForObject):
* UserInterface/Controllers/RuntimeManager.js:
(WebInspector.RuntimeManager.prototype.evaluateInInspectedWindow):
* UserInterface/Protocol/RemoteObject.js:
(WebInspector.RemoteObject.prototype.findFunctionSourceCodeLocation):
Use target specific DebuggerAgent where necessary.
* UserInterface/Controllers/JavaScriptRuntimeCompletionProvider.js:
* UserInterface/Controllers/TimelineManager.js:
(WebInspector.TimelineManager.prototype._callFramesFromPayload):
* UserInterface/Models/ScriptTimelineRecord.js:
(WebInspector.ScriptTimelineRecord.prototype._initializeProfileFromPayload.profileNodeFromPayload):
* UserInterface/Views/EventListenerSectionGroup.js:
(WebInspector.EventListenerSectionGroup.prototype._functionTextOrLink):
(WebInspector.EventListenerSectionGroup):
* UserInterface/Views/HeapSnapshotInstanceDataGridNode.js:
(WebInspector.HeapSnapshotInstanceDataGridNode.logHeapSnapshotNode.node.shortestGCRootPath.):
(WebInspector.HeapSnapshotInstanceDataGridNode.logHeapSnapshotNode):
(WebInspector.HeapSnapshotInstanceDataGridNode.prototype._populateWindowPreview):
(WebInspector.HeapSnapshotInstanceDataGridNode.prototype._populatePreview):
(WebInspector.HeapSnapshotInstanceDataGridNode.prototype._mouseoverHandler.appendPathRow):
* UserInterface/Views/ProfileDataGridNode.js:
(WebInspector.ProfileDataGridNode.prototype.iconClassName):
(WebInspector.ProfileDataGridNode.prototype.filterableDataForColumn):
(WebInspector.ProfileDataGridNode.prototype._displayContent):
Use assumed main target and audit these when the Worker gets more Agents.
* UserInterface/Controllers/FrameResourceManager.js:
(WebInspector.FrameResourceManager.prototype._initiatorSourceCodeLocationFromPayload):
This will always be the main target because only the main target
has access to the DOM.
* UserInterface/Views/SourceCodeTextEditor.js:
(WebInspector.SourceCodeTextEditor.prototype.get target):
(WebInspector.SourceCodeTextEditor.prototype.customPerformSearch):
(WebInspector.SourceCodeTextEditor.prototype.textEditorGutterContextMenu):
(WebInspector.SourceCodeTextEditor.prototype._tokenTrackingControllerHighlightedJavaScriptExpression.populate):
(WebInspector.SourceCodeTextEditor.prototype._tokenTrackingControllerHighlightedJavaScriptExpression):
(WebInspector.SourceCodeTextEditor.prototype._showPopoverForFunction.didGetDetails):
(WebInspector.SourceCodeTextEditor.prototype._showPopoverForFunction):
Update target specific actions to use the proper target's agents.
* UserInterface/Views/TargetTreeElement.js: Added.
(WebInspector.TargetTreeElement):
(WebInspector.TargetTreeElement.prototype.get target):
(WebInspector.TargetTreeElement.prototype.onexpand):
(WebInspector.TargetTreeElement.prototype.oncollapse):
Add a new tree element for a Target. We currently assume that the
main resource for a Target will be a Script right now, as is the
case for Web Workers. This simply remembers its expanded or
collapsed state and has a better icon.
* UserInterface/Views/ResourceIcons.css:
(body:matches(.mac-platform, .windows-platform) .script.worker-icon .icon):
(body:matches(.mac-platform, .windows-platform) .large .script.worker-icon .icon):
* UserInterface/Images/WorkerScript.png: Renamed from Source/WebInspectorUI/UserInterface/Images/WorkerDocument.png.
* UserInterface/Images/WorkerScript@2x.png: Renamed from Source/WebInspectorUI/UserInterface/Images/WorkerDocument@2x.png.
* UserInterface/Images/WorkerScriptLarge.png: Renamed from Source/WebInspectorUI/UserInterface/Images/WorkerDocumentLarge.png.
* UserInterface/Images/WorkerScriptLarge@2x.png: Renamed from Source/WebInspectorUI/UserInterface/Images/WorkerDocumentLarge@2x.png.
Improve icon for a Worker's main resource script.
* UserInterface/Views/ResourceSidebarPanel.js:
(WebInspector.ResourceSidebarPanel):
(WebInspector.ResourceSidebarPanel.prototype._scriptWasAdded):
(WebInspector.ResourceSidebarPanel.prototype._scriptsCleared):
(WebInspector.ResourceSidebarPanel.prototype._addScriptForNonMainTarget):
(WebInspector.ResourceSidebarPanel.prototype._addTargetWithMainResource):
(WebInspector.ResourceSidebarPanel.prototype._targetRemoved):
* UserInterface/Views/SearchSidebarPanel.js:
(WebInspector.SearchSidebarPanel.prototype.performSearch.searchScripts):
(WebInspector.SearchSidebarPanel.prototype._searchTreeElementForScript):
* UserInterface/Views/OpenResourceDialog.js:
(WebInspector.OpenResourceDialog.prototype._populateResourceTreeOutline.createTreeElement):
(WebInspector.OpenResourceDialog.prototype._populateResourceTreeOutline):
(WebInspector.OpenResourceDialog.prototype.didDismissDialog):
(WebInspector.OpenResourceDialog.prototype.didPresentDialog):
(WebInspector.OpenResourceDialog.prototype._addResourcesForFrame):
(WebInspector.OpenResourceDialog.prototype._addScriptsForTarget):
(WebInspector.OpenResourceDialog.prototype._scriptAdded):
(WebInspector.OpenResourceDialog):
* UserInterface/Views/DebuggerSidebarPanel.js:
(WebInspector.DebuggerSidebarPanel.prototype._addTreeElementForSourceCodeToTreeOutline):
(WebInspector.DebuggerSidebarPanel.prototype._debuggerCallFramesDidChange):
(WebInspector.DebuggerSidebarPanel.prototype._debuggerActiveCallFrameDidChange):
(WebInspector.DebuggerSidebarPanel.prototype._updatePauseReasonSection):
Include scripts from non-main targets in sidebars.
LayoutTests:
* inspector/worker/debugger-pause-expected.txt: Added.
* inspector/worker/debugger-pause.html: Added.
* inspector/worker/debugger-scripts-expected.txt: Added.
* inspector/worker/debugger-scripts.html: Added.
* inspector/worker/resources/worker-debugger-pause.js: Added.
* inspector/worker/resources/worker-import-1.js: Added.
* inspector/worker/resources/worker-scripts.js: Added.
New tests for Debugger features in a Worker.
* inspector/debugger/break-on-exception-throw-in-promise.html:
* inspector/debugger/break-on-exception.html:
* inspector/debugger/break-on-uncaught-exception.html:
* inspector/debugger/evaluateOnCallFrame-CommandLineAPI.html:
* inspector/debugger/pause-reason.html:
* inspector/debugger/paused-scopes.html:
* inspector/debugger/resources/log-pause-location.js:
* inspector/debugger/stepping/stepInto.html:
* inspector/debugger/stepping/stepOut.html:
* inspector/debugger/stepping/stepOver.html:
* inspector/debugger/stepping/stepping-through-autoContinue-breakpoint.html:
* inspector/debugger/tail-deleted-frames-from-vm-entry.html:
* inspector/debugger/tail-deleted-frames-this-value.html:
* inspector/debugger/tail-deleted-frames.html:
* inspector/debugger/tail-recursion.html:
Most debugger data moved from DebuggerManager into DebuggerData for a target.
Update tests that access such data like pauseReason / pauseData / callFrames.
Canonical link: https://commits.webkit.org/182063@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@208304 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-11-02 21:51:36 +00:00
|
|
|
let callFrames = targetData.callFrames;
|
2016-09-17 03:53:29 +00:00
|
|
|
let chain = Promise.resolve();
|
|
|
|
|
for (let callFrame of callFrames)
|
|
|
|
|
chain = chain.then(() => dumpCallFrame(callFrame));
|
|
|
|
|
return chain;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
let suite = InspectorTest.createAsyncSuite("PausedCallFrameScope");
|
|
|
|
|
|
|
|
|
|
suite.addTestCase({
|
2016-09-19 18:59:22 +00:00
|
|
|
name: "PausedCallFrameScope.TriggerFirstPause",
|
|
|
|
|
description: "Dump CallFrames and Scopes with the first pause.",
|
Web Inspector: DebuggerManager.Event.Resumed introduces test flakiness
https://bugs.webkit.org/show_bug.cgi?id=161951
<rdar://problem/28295767>
Reviewed by Brian Burg.
Source/JavaScriptCore:
This removes an ambiguity in the protocol when stepping through
JavaScript. Previously, when paused and issuing a Debugger.step*
command the frontend would always receive a Debugger.resumed event and
then, maybe, a Debugger.paused event indicating we paused again (after
stepping). However, this ambiguity means that the frontend needs to
wait for a short period of time to determine if we really resumed
or not. And even still that decision may be incorrect if the step
takes a sufficiently long period of time.
The new approach removes this ambiguity. Now, in response to a
Debugger.step* command the backend MUST send a single Debugger.paused
event or Debugger.resumed event. Now the frontend knows that the
next Debugger event it receives after issuing the step command is
the result (stepped and paused, or stepped and resumed).
To make resuming consistent in all cases, a Debugger.resume command
will always respond with a Debugger.resumed event.
Finally, Debugger.continueToLocation is treated like a "big step"
in cases where we can resolve the location. If we can't resolve the
location it is treated as a resume, maintaining the old behavior.
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::stepOver):
(Inspector::InspectorDebuggerAgent::stepInto):
(Inspector::InspectorDebuggerAgent::stepOut):
(Inspector::InspectorDebuggerAgent::willStepAndMayBecomeIdle):
(Inspector::InspectorDebuggerAgent::didBecomeIdleAfterStepping):
When stepping register a VM exit observer so that we can issue
a Debugger.resumed event if the step caused us to exit the VM.
(Inspector::InspectorDebuggerAgent::resume):
Set a flag to issue a Debugger.resumed event once we break out
of the nested run loop.
(Inspector::InspectorDebuggerAgent::didPause):
We are issuing Debugger.paused so clear the state to indicate that
we no longer need to issue Debugger.resumed event, we have paused.
(Inspector::InspectorDebuggerAgent::didContinue):
Only issue the Debugger.resumed event if needed (explicitly asked
to resume).
(Inspector::InspectorDebuggerAgent::continueToLocation):
(Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState):
All places that do continueProgram should be audited. In error cases,
if we are paused and continue we should remember to send Debugger.resumed.
* inspector/protocol/Debugger.json:
Clarify in the protocol description the contract of these methods.
Source/WebCore:
Covered by existing tests that would ASSERT otherwise.
* inspector/InspectorClient.cpp:
(WebCore::InspectorClient::doDispatchMessageOnFrontendPage):
When paused on an exception in the inspected page and evaluating
commands in the inspector frontend page (which evaluates JavaScript)
we ASSERT when entering the Global DOM VM with an existing exception.
This makes it so when we evaluate JavaScript in the frontend we
suspend / ignore the state of the VM for the inspected page, and
restore it when we return from the inspector.
Source/WebInspectorUI:
* UserInterface/Controllers/DebuggerManager.js:
(WebInspector.DebuggerManager.prototype.debuggerDidResume):
Now, Debugger.resumed events really mean the debugger resumed,
so act immediately instead of guessing. We must still guess
in legacy backends.
* UserInterface/Test/Test.js:
When the inspector frontend encounters an issue, log it.
* UserInterface/Views/DebuggerSidebarPanel.js:
(WebInspector.DebuggerSidebarPanel.prototype._debuggerDidPause):
(WebInspector.DebuggerSidebarPanel.prototype._debuggerActiveCallFrameDidChange):
Always enable the step out button. I don't think it makes sense to disable
it sometimes, and if there are issues with this we should solve the issues
instead of hiding them.
LayoutTests:
Rewrite tests to be more deterministic. For tests that
relied on a Resumed event to happen after a short amount
of time, instead have the test dispatch an event when it is
appropriate to continue. Take this opportunity to rewrite
some tests using new style and best practices.
* inspector/debugger/break-in-constructor-before-super.html:
* inspector/debugger/break-on-exception-throw-in-promise.html:
* inspector/debugger/break-on-exception.html:
* inspector/debugger/break-on-uncaught-exception-throw-in-promise.html:
* inspector/debugger/break-on-uncaught-exception.html:
* inspector/debugger/breakpoint-syntax-error-top-level.html:
* inspector/debugger/command-line-api-exception-expected.txt:
* inspector/debugger/command-line-api-exception-nested-catch.html:
* inspector/debugger/command-line-api-exception.html:
* inspector/debugger/csp-exceptions.html:
* inspector/debugger/didSampleProbe-multiple-probes.html:
* inspector/debugger/evaluateOnCallFrame-CommandLineAPI.html:
* inspector/debugger/evaluateOnCallFrame-errors.html:
* inspector/debugger/pause-reason-expected.txt:
* inspector/debugger/pause-reason.html:
* inspector/debugger/paused-scopes-expected.txt:
* inspector/debugger/paused-scopes.html:
* inspector/debugger/resources/exceptions.js:
* inspector/debugger/scriptParsed.html:
* inspector/debugger/sourceURL-repeated-identical-executions.html:
* inspector/debugger/sourceURLs.html:
* inspector/debugger/stepping/stepping-pause-in-inner-step-to-parent.html:
Canonical link: https://commits.webkit.org/182248@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@208523 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-11-10 06:07:07 +00:00
|
|
|
test(resolve, reject) {
|
2016-09-17 03:53:29 +00:00
|
|
|
InspectorTest.evaluateInPage("setTimeout(entry)");
|
2017-08-02 03:09:57 +00:00
|
|
|
WI.debuggerManager.singleFireEventListener(WI.DebuggerManager.Event.Paused, (event) => {
|
2016-09-17 03:53:29 +00:00
|
|
|
dumpCallFrames().then(resolve, reject);
|
|
|
|
|
});
|
|
|
|
|
}
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
suite.addTestCase({
|
2016-09-19 18:59:22 +00:00
|
|
|
name: "PausedCallFrameScope.TriggerSecondPause",
|
|
|
|
|
description: "Dump CallFrames and Scopes with the second pause.",
|
Web Inspector: DebuggerManager.Event.Resumed introduces test flakiness
https://bugs.webkit.org/show_bug.cgi?id=161951
<rdar://problem/28295767>
Reviewed by Brian Burg.
Source/JavaScriptCore:
This removes an ambiguity in the protocol when stepping through
JavaScript. Previously, when paused and issuing a Debugger.step*
command the frontend would always receive a Debugger.resumed event and
then, maybe, a Debugger.paused event indicating we paused again (after
stepping). However, this ambiguity means that the frontend needs to
wait for a short period of time to determine if we really resumed
or not. And even still that decision may be incorrect if the step
takes a sufficiently long period of time.
The new approach removes this ambiguity. Now, in response to a
Debugger.step* command the backend MUST send a single Debugger.paused
event or Debugger.resumed event. Now the frontend knows that the
next Debugger event it receives after issuing the step command is
the result (stepped and paused, or stepped and resumed).
To make resuming consistent in all cases, a Debugger.resume command
will always respond with a Debugger.resumed event.
Finally, Debugger.continueToLocation is treated like a "big step"
in cases where we can resolve the location. If we can't resolve the
location it is treated as a resume, maintaining the old behavior.
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::stepOver):
(Inspector::InspectorDebuggerAgent::stepInto):
(Inspector::InspectorDebuggerAgent::stepOut):
(Inspector::InspectorDebuggerAgent::willStepAndMayBecomeIdle):
(Inspector::InspectorDebuggerAgent::didBecomeIdleAfterStepping):
When stepping register a VM exit observer so that we can issue
a Debugger.resumed event if the step caused us to exit the VM.
(Inspector::InspectorDebuggerAgent::resume):
Set a flag to issue a Debugger.resumed event once we break out
of the nested run loop.
(Inspector::InspectorDebuggerAgent::didPause):
We are issuing Debugger.paused so clear the state to indicate that
we no longer need to issue Debugger.resumed event, we have paused.
(Inspector::InspectorDebuggerAgent::didContinue):
Only issue the Debugger.resumed event if needed (explicitly asked
to resume).
(Inspector::InspectorDebuggerAgent::continueToLocation):
(Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState):
All places that do continueProgram should be audited. In error cases,
if we are paused and continue we should remember to send Debugger.resumed.
* inspector/protocol/Debugger.json:
Clarify in the protocol description the contract of these methods.
Source/WebCore:
Covered by existing tests that would ASSERT otherwise.
* inspector/InspectorClient.cpp:
(WebCore::InspectorClient::doDispatchMessageOnFrontendPage):
When paused on an exception in the inspected page and evaluating
commands in the inspector frontend page (which evaluates JavaScript)
we ASSERT when entering the Global DOM VM with an existing exception.
This makes it so when we evaluate JavaScript in the frontend we
suspend / ignore the state of the VM for the inspected page, and
restore it when we return from the inspector.
Source/WebInspectorUI:
* UserInterface/Controllers/DebuggerManager.js:
(WebInspector.DebuggerManager.prototype.debuggerDidResume):
Now, Debugger.resumed events really mean the debugger resumed,
so act immediately instead of guessing. We must still guess
in legacy backends.
* UserInterface/Test/Test.js:
When the inspector frontend encounters an issue, log it.
* UserInterface/Views/DebuggerSidebarPanel.js:
(WebInspector.DebuggerSidebarPanel.prototype._debuggerDidPause):
(WebInspector.DebuggerSidebarPanel.prototype._debuggerActiveCallFrameDidChange):
Always enable the step out button. I don't think it makes sense to disable
it sometimes, and if there are issues with this we should solve the issues
instead of hiding them.
LayoutTests:
Rewrite tests to be more deterministic. For tests that
relied on a Resumed event to happen after a short amount
of time, instead have the test dispatch an event when it is
appropriate to continue. Take this opportunity to rewrite
some tests using new style and best practices.
* inspector/debugger/break-in-constructor-before-super.html:
* inspector/debugger/break-on-exception-throw-in-promise.html:
* inspector/debugger/break-on-exception.html:
* inspector/debugger/break-on-uncaught-exception-throw-in-promise.html:
* inspector/debugger/break-on-uncaught-exception.html:
* inspector/debugger/breakpoint-syntax-error-top-level.html:
* inspector/debugger/command-line-api-exception-expected.txt:
* inspector/debugger/command-line-api-exception-nested-catch.html:
* inspector/debugger/command-line-api-exception.html:
* inspector/debugger/csp-exceptions.html:
* inspector/debugger/didSampleProbe-multiple-probes.html:
* inspector/debugger/evaluateOnCallFrame-CommandLineAPI.html:
* inspector/debugger/evaluateOnCallFrame-errors.html:
* inspector/debugger/pause-reason-expected.txt:
* inspector/debugger/pause-reason.html:
* inspector/debugger/paused-scopes-expected.txt:
* inspector/debugger/paused-scopes.html:
* inspector/debugger/resources/exceptions.js:
* inspector/debugger/scriptParsed.html:
* inspector/debugger/sourceURL-repeated-identical-executions.html:
* inspector/debugger/sourceURLs.html:
* inspector/debugger/stepping/stepping-pause-in-inner-step-to-parent.html:
Canonical link: https://commits.webkit.org/182248@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@208523 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-11-10 06:07:07 +00:00
|
|
|
test(resolve, reject) {
|
2017-08-02 03:09:57 +00:00
|
|
|
WI.debuggerManager.resume();
|
|
|
|
|
WI.debuggerManager.singleFireEventListener(WI.DebuggerManager.Event.Paused, (event) => {
|
Web Inspector: DebuggerManager.Event.Resumed introduces test flakiness
https://bugs.webkit.org/show_bug.cgi?id=161951
<rdar://problem/28295767>
Reviewed by Brian Burg.
Source/JavaScriptCore:
This removes an ambiguity in the protocol when stepping through
JavaScript. Previously, when paused and issuing a Debugger.step*
command the frontend would always receive a Debugger.resumed event and
then, maybe, a Debugger.paused event indicating we paused again (after
stepping). However, this ambiguity means that the frontend needs to
wait for a short period of time to determine if we really resumed
or not. And even still that decision may be incorrect if the step
takes a sufficiently long period of time.
The new approach removes this ambiguity. Now, in response to a
Debugger.step* command the backend MUST send a single Debugger.paused
event or Debugger.resumed event. Now the frontend knows that the
next Debugger event it receives after issuing the step command is
the result (stepped and paused, or stepped and resumed).
To make resuming consistent in all cases, a Debugger.resume command
will always respond with a Debugger.resumed event.
Finally, Debugger.continueToLocation is treated like a "big step"
in cases where we can resolve the location. If we can't resolve the
location it is treated as a resume, maintaining the old behavior.
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::stepOver):
(Inspector::InspectorDebuggerAgent::stepInto):
(Inspector::InspectorDebuggerAgent::stepOut):
(Inspector::InspectorDebuggerAgent::willStepAndMayBecomeIdle):
(Inspector::InspectorDebuggerAgent::didBecomeIdleAfterStepping):
When stepping register a VM exit observer so that we can issue
a Debugger.resumed event if the step caused us to exit the VM.
(Inspector::InspectorDebuggerAgent::resume):
Set a flag to issue a Debugger.resumed event once we break out
of the nested run loop.
(Inspector::InspectorDebuggerAgent::didPause):
We are issuing Debugger.paused so clear the state to indicate that
we no longer need to issue Debugger.resumed event, we have paused.
(Inspector::InspectorDebuggerAgent::didContinue):
Only issue the Debugger.resumed event if needed (explicitly asked
to resume).
(Inspector::InspectorDebuggerAgent::continueToLocation):
(Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState):
All places that do continueProgram should be audited. In error cases,
if we are paused and continue we should remember to send Debugger.resumed.
* inspector/protocol/Debugger.json:
Clarify in the protocol description the contract of these methods.
Source/WebCore:
Covered by existing tests that would ASSERT otherwise.
* inspector/InspectorClient.cpp:
(WebCore::InspectorClient::doDispatchMessageOnFrontendPage):
When paused on an exception in the inspected page and evaluating
commands in the inspector frontend page (which evaluates JavaScript)
we ASSERT when entering the Global DOM VM with an existing exception.
This makes it so when we evaluate JavaScript in the frontend we
suspend / ignore the state of the VM for the inspected page, and
restore it when we return from the inspector.
Source/WebInspectorUI:
* UserInterface/Controllers/DebuggerManager.js:
(WebInspector.DebuggerManager.prototype.debuggerDidResume):
Now, Debugger.resumed events really mean the debugger resumed,
so act immediately instead of guessing. We must still guess
in legacy backends.
* UserInterface/Test/Test.js:
When the inspector frontend encounters an issue, log it.
* UserInterface/Views/DebuggerSidebarPanel.js:
(WebInspector.DebuggerSidebarPanel.prototype._debuggerDidPause):
(WebInspector.DebuggerSidebarPanel.prototype._debuggerActiveCallFrameDidChange):
Always enable the step out button. I don't think it makes sense to disable
it sometimes, and if there are issues with this we should solve the issues
instead of hiding them.
LayoutTests:
Rewrite tests to be more deterministic. For tests that
relied on a Resumed event to happen after a short amount
of time, instead have the test dispatch an event when it is
appropriate to continue. Take this opportunity to rewrite
some tests using new style and best practices.
* inspector/debugger/break-in-constructor-before-super.html:
* inspector/debugger/break-on-exception-throw-in-promise.html:
* inspector/debugger/break-on-exception.html:
* inspector/debugger/break-on-uncaught-exception-throw-in-promise.html:
* inspector/debugger/break-on-uncaught-exception.html:
* inspector/debugger/breakpoint-syntax-error-top-level.html:
* inspector/debugger/command-line-api-exception-expected.txt:
* inspector/debugger/command-line-api-exception-nested-catch.html:
* inspector/debugger/command-line-api-exception.html:
* inspector/debugger/csp-exceptions.html:
* inspector/debugger/didSampleProbe-multiple-probes.html:
* inspector/debugger/evaluateOnCallFrame-CommandLineAPI.html:
* inspector/debugger/evaluateOnCallFrame-errors.html:
* inspector/debugger/pause-reason-expected.txt:
* inspector/debugger/pause-reason.html:
* inspector/debugger/paused-scopes-expected.txt:
* inspector/debugger/paused-scopes.html:
* inspector/debugger/resources/exceptions.js:
* inspector/debugger/scriptParsed.html:
* inspector/debugger/sourceURL-repeated-identical-executions.html:
* inspector/debugger/sourceURLs.html:
* inspector/debugger/stepping/stepping-pause-in-inner-step-to-parent.html:
Canonical link: https://commits.webkit.org/182248@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@208523 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-11-10 06:07:07 +00:00
|
|
|
dumpCallFrames().then(resolve, reject);
|
2016-09-19 18:59:22 +00:00
|
|
|
});
|
|
|
|
|
}
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
suite.addTestCase({
|
|
|
|
|
name: "PausedCallFrameScope.TriggerThirdPause",
|
|
|
|
|
description: "Dump CallFrames and Scopes with the third pause.",
|
Web Inspector: DebuggerManager.Event.Resumed introduces test flakiness
https://bugs.webkit.org/show_bug.cgi?id=161951
<rdar://problem/28295767>
Reviewed by Brian Burg.
Source/JavaScriptCore:
This removes an ambiguity in the protocol when stepping through
JavaScript. Previously, when paused and issuing a Debugger.step*
command the frontend would always receive a Debugger.resumed event and
then, maybe, a Debugger.paused event indicating we paused again (after
stepping). However, this ambiguity means that the frontend needs to
wait for a short period of time to determine if we really resumed
or not. And even still that decision may be incorrect if the step
takes a sufficiently long period of time.
The new approach removes this ambiguity. Now, in response to a
Debugger.step* command the backend MUST send a single Debugger.paused
event or Debugger.resumed event. Now the frontend knows that the
next Debugger event it receives after issuing the step command is
the result (stepped and paused, or stepped and resumed).
To make resuming consistent in all cases, a Debugger.resume command
will always respond with a Debugger.resumed event.
Finally, Debugger.continueToLocation is treated like a "big step"
in cases where we can resolve the location. If we can't resolve the
location it is treated as a resume, maintaining the old behavior.
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::stepOver):
(Inspector::InspectorDebuggerAgent::stepInto):
(Inspector::InspectorDebuggerAgent::stepOut):
(Inspector::InspectorDebuggerAgent::willStepAndMayBecomeIdle):
(Inspector::InspectorDebuggerAgent::didBecomeIdleAfterStepping):
When stepping register a VM exit observer so that we can issue
a Debugger.resumed event if the step caused us to exit the VM.
(Inspector::InspectorDebuggerAgent::resume):
Set a flag to issue a Debugger.resumed event once we break out
of the nested run loop.
(Inspector::InspectorDebuggerAgent::didPause):
We are issuing Debugger.paused so clear the state to indicate that
we no longer need to issue Debugger.resumed event, we have paused.
(Inspector::InspectorDebuggerAgent::didContinue):
Only issue the Debugger.resumed event if needed (explicitly asked
to resume).
(Inspector::InspectorDebuggerAgent::continueToLocation):
(Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState):
All places that do continueProgram should be audited. In error cases,
if we are paused and continue we should remember to send Debugger.resumed.
* inspector/protocol/Debugger.json:
Clarify in the protocol description the contract of these methods.
Source/WebCore:
Covered by existing tests that would ASSERT otherwise.
* inspector/InspectorClient.cpp:
(WebCore::InspectorClient::doDispatchMessageOnFrontendPage):
When paused on an exception in the inspected page and evaluating
commands in the inspector frontend page (which evaluates JavaScript)
we ASSERT when entering the Global DOM VM with an existing exception.
This makes it so when we evaluate JavaScript in the frontend we
suspend / ignore the state of the VM for the inspected page, and
restore it when we return from the inspector.
Source/WebInspectorUI:
* UserInterface/Controllers/DebuggerManager.js:
(WebInspector.DebuggerManager.prototype.debuggerDidResume):
Now, Debugger.resumed events really mean the debugger resumed,
so act immediately instead of guessing. We must still guess
in legacy backends.
* UserInterface/Test/Test.js:
When the inspector frontend encounters an issue, log it.
* UserInterface/Views/DebuggerSidebarPanel.js:
(WebInspector.DebuggerSidebarPanel.prototype._debuggerDidPause):
(WebInspector.DebuggerSidebarPanel.prototype._debuggerActiveCallFrameDidChange):
Always enable the step out button. I don't think it makes sense to disable
it sometimes, and if there are issues with this we should solve the issues
instead of hiding them.
LayoutTests:
Rewrite tests to be more deterministic. For tests that
relied on a Resumed event to happen after a short amount
of time, instead have the test dispatch an event when it is
appropriate to continue. Take this opportunity to rewrite
some tests using new style and best practices.
* inspector/debugger/break-in-constructor-before-super.html:
* inspector/debugger/break-on-exception-throw-in-promise.html:
* inspector/debugger/break-on-exception.html:
* inspector/debugger/break-on-uncaught-exception-throw-in-promise.html:
* inspector/debugger/break-on-uncaught-exception.html:
* inspector/debugger/breakpoint-syntax-error-top-level.html:
* inspector/debugger/command-line-api-exception-expected.txt:
* inspector/debugger/command-line-api-exception-nested-catch.html:
* inspector/debugger/command-line-api-exception.html:
* inspector/debugger/csp-exceptions.html:
* inspector/debugger/didSampleProbe-multiple-probes.html:
* inspector/debugger/evaluateOnCallFrame-CommandLineAPI.html:
* inspector/debugger/evaluateOnCallFrame-errors.html:
* inspector/debugger/pause-reason-expected.txt:
* inspector/debugger/pause-reason.html:
* inspector/debugger/paused-scopes-expected.txt:
* inspector/debugger/paused-scopes.html:
* inspector/debugger/resources/exceptions.js:
* inspector/debugger/scriptParsed.html:
* inspector/debugger/sourceURL-repeated-identical-executions.html:
* inspector/debugger/sourceURLs.html:
* inspector/debugger/stepping/stepping-pause-in-inner-step-to-parent.html:
Canonical link: https://commits.webkit.org/182248@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@208523 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-11-10 06:07:07 +00:00
|
|
|
test(resolve, reject) {
|
2017-08-02 03:09:57 +00:00
|
|
|
WI.debuggerManager.resume();
|
|
|
|
|
WI.debuggerManager.singleFireEventListener(WI.DebuggerManager.Event.Paused, (event) => {
|
Web Inspector: DebuggerManager.Event.Resumed introduces test flakiness
https://bugs.webkit.org/show_bug.cgi?id=161951
<rdar://problem/28295767>
Reviewed by Brian Burg.
Source/JavaScriptCore:
This removes an ambiguity in the protocol when stepping through
JavaScript. Previously, when paused and issuing a Debugger.step*
command the frontend would always receive a Debugger.resumed event and
then, maybe, a Debugger.paused event indicating we paused again (after
stepping). However, this ambiguity means that the frontend needs to
wait for a short period of time to determine if we really resumed
or not. And even still that decision may be incorrect if the step
takes a sufficiently long period of time.
The new approach removes this ambiguity. Now, in response to a
Debugger.step* command the backend MUST send a single Debugger.paused
event or Debugger.resumed event. Now the frontend knows that the
next Debugger event it receives after issuing the step command is
the result (stepped and paused, or stepped and resumed).
To make resuming consistent in all cases, a Debugger.resume command
will always respond with a Debugger.resumed event.
Finally, Debugger.continueToLocation is treated like a "big step"
in cases where we can resolve the location. If we can't resolve the
location it is treated as a resume, maintaining the old behavior.
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::stepOver):
(Inspector::InspectorDebuggerAgent::stepInto):
(Inspector::InspectorDebuggerAgent::stepOut):
(Inspector::InspectorDebuggerAgent::willStepAndMayBecomeIdle):
(Inspector::InspectorDebuggerAgent::didBecomeIdleAfterStepping):
When stepping register a VM exit observer so that we can issue
a Debugger.resumed event if the step caused us to exit the VM.
(Inspector::InspectorDebuggerAgent::resume):
Set a flag to issue a Debugger.resumed event once we break out
of the nested run loop.
(Inspector::InspectorDebuggerAgent::didPause):
We are issuing Debugger.paused so clear the state to indicate that
we no longer need to issue Debugger.resumed event, we have paused.
(Inspector::InspectorDebuggerAgent::didContinue):
Only issue the Debugger.resumed event if needed (explicitly asked
to resume).
(Inspector::InspectorDebuggerAgent::continueToLocation):
(Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState):
All places that do continueProgram should be audited. In error cases,
if we are paused and continue we should remember to send Debugger.resumed.
* inspector/protocol/Debugger.json:
Clarify in the protocol description the contract of these methods.
Source/WebCore:
Covered by existing tests that would ASSERT otherwise.
* inspector/InspectorClient.cpp:
(WebCore::InspectorClient::doDispatchMessageOnFrontendPage):
When paused on an exception in the inspected page and evaluating
commands in the inspector frontend page (which evaluates JavaScript)
we ASSERT when entering the Global DOM VM with an existing exception.
This makes it so when we evaluate JavaScript in the frontend we
suspend / ignore the state of the VM for the inspected page, and
restore it when we return from the inspector.
Source/WebInspectorUI:
* UserInterface/Controllers/DebuggerManager.js:
(WebInspector.DebuggerManager.prototype.debuggerDidResume):
Now, Debugger.resumed events really mean the debugger resumed,
so act immediately instead of guessing. We must still guess
in legacy backends.
* UserInterface/Test/Test.js:
When the inspector frontend encounters an issue, log it.
* UserInterface/Views/DebuggerSidebarPanel.js:
(WebInspector.DebuggerSidebarPanel.prototype._debuggerDidPause):
(WebInspector.DebuggerSidebarPanel.prototype._debuggerActiveCallFrameDidChange):
Always enable the step out button. I don't think it makes sense to disable
it sometimes, and if there are issues with this we should solve the issues
instead of hiding them.
LayoutTests:
Rewrite tests to be more deterministic. For tests that
relied on a Resumed event to happen after a short amount
of time, instead have the test dispatch an event when it is
appropriate to continue. Take this opportunity to rewrite
some tests using new style and best practices.
* inspector/debugger/break-in-constructor-before-super.html:
* inspector/debugger/break-on-exception-throw-in-promise.html:
* inspector/debugger/break-on-exception.html:
* inspector/debugger/break-on-uncaught-exception-throw-in-promise.html:
* inspector/debugger/break-on-uncaught-exception.html:
* inspector/debugger/breakpoint-syntax-error-top-level.html:
* inspector/debugger/command-line-api-exception-expected.txt:
* inspector/debugger/command-line-api-exception-nested-catch.html:
* inspector/debugger/command-line-api-exception.html:
* inspector/debugger/csp-exceptions.html:
* inspector/debugger/didSampleProbe-multiple-probes.html:
* inspector/debugger/evaluateOnCallFrame-CommandLineAPI.html:
* inspector/debugger/evaluateOnCallFrame-errors.html:
* inspector/debugger/pause-reason-expected.txt:
* inspector/debugger/pause-reason.html:
* inspector/debugger/paused-scopes-expected.txt:
* inspector/debugger/paused-scopes.html:
* inspector/debugger/resources/exceptions.js:
* inspector/debugger/scriptParsed.html:
* inspector/debugger/sourceURL-repeated-identical-executions.html:
* inspector/debugger/sourceURLs.html:
* inspector/debugger/stepping/stepping-pause-in-inner-step-to-parent.html:
Canonical link: https://commits.webkit.org/182248@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@208523 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-11-10 06:07:07 +00:00
|
|
|
dumpCallFrames().then(resolve, reject);
|
2016-09-17 03:53:29 +00:00
|
|
|
});
|
|
|
|
|
}
|
|
|
|
|
});
|
|
|
|
|
|
Web Inspector: DebuggerManager.Event.Resumed introduces test flakiness
https://bugs.webkit.org/show_bug.cgi?id=161951
<rdar://problem/28295767>
Reviewed by Brian Burg.
Source/JavaScriptCore:
This removes an ambiguity in the protocol when stepping through
JavaScript. Previously, when paused and issuing a Debugger.step*
command the frontend would always receive a Debugger.resumed event and
then, maybe, a Debugger.paused event indicating we paused again (after
stepping). However, this ambiguity means that the frontend needs to
wait for a short period of time to determine if we really resumed
or not. And even still that decision may be incorrect if the step
takes a sufficiently long period of time.
The new approach removes this ambiguity. Now, in response to a
Debugger.step* command the backend MUST send a single Debugger.paused
event or Debugger.resumed event. Now the frontend knows that the
next Debugger event it receives after issuing the step command is
the result (stepped and paused, or stepped and resumed).
To make resuming consistent in all cases, a Debugger.resume command
will always respond with a Debugger.resumed event.
Finally, Debugger.continueToLocation is treated like a "big step"
in cases where we can resolve the location. If we can't resolve the
location it is treated as a resume, maintaining the old behavior.
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::stepOver):
(Inspector::InspectorDebuggerAgent::stepInto):
(Inspector::InspectorDebuggerAgent::stepOut):
(Inspector::InspectorDebuggerAgent::willStepAndMayBecomeIdle):
(Inspector::InspectorDebuggerAgent::didBecomeIdleAfterStepping):
When stepping register a VM exit observer so that we can issue
a Debugger.resumed event if the step caused us to exit the VM.
(Inspector::InspectorDebuggerAgent::resume):
Set a flag to issue a Debugger.resumed event once we break out
of the nested run loop.
(Inspector::InspectorDebuggerAgent::didPause):
We are issuing Debugger.paused so clear the state to indicate that
we no longer need to issue Debugger.resumed event, we have paused.
(Inspector::InspectorDebuggerAgent::didContinue):
Only issue the Debugger.resumed event if needed (explicitly asked
to resume).
(Inspector::InspectorDebuggerAgent::continueToLocation):
(Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState):
All places that do continueProgram should be audited. In error cases,
if we are paused and continue we should remember to send Debugger.resumed.
* inspector/protocol/Debugger.json:
Clarify in the protocol description the contract of these methods.
Source/WebCore:
Covered by existing tests that would ASSERT otherwise.
* inspector/InspectorClient.cpp:
(WebCore::InspectorClient::doDispatchMessageOnFrontendPage):
When paused on an exception in the inspected page and evaluating
commands in the inspector frontend page (which evaluates JavaScript)
we ASSERT when entering the Global DOM VM with an existing exception.
This makes it so when we evaluate JavaScript in the frontend we
suspend / ignore the state of the VM for the inspected page, and
restore it when we return from the inspector.
Source/WebInspectorUI:
* UserInterface/Controllers/DebuggerManager.js:
(WebInspector.DebuggerManager.prototype.debuggerDidResume):
Now, Debugger.resumed events really mean the debugger resumed,
so act immediately instead of guessing. We must still guess
in legacy backends.
* UserInterface/Test/Test.js:
When the inspector frontend encounters an issue, log it.
* UserInterface/Views/DebuggerSidebarPanel.js:
(WebInspector.DebuggerSidebarPanel.prototype._debuggerDidPause):
(WebInspector.DebuggerSidebarPanel.prototype._debuggerActiveCallFrameDidChange):
Always enable the step out button. I don't think it makes sense to disable
it sometimes, and if there are issues with this we should solve the issues
instead of hiding them.
LayoutTests:
Rewrite tests to be more deterministic. For tests that
relied on a Resumed event to happen after a short amount
of time, instead have the test dispatch an event when it is
appropriate to continue. Take this opportunity to rewrite
some tests using new style and best practices.
* inspector/debugger/break-in-constructor-before-super.html:
* inspector/debugger/break-on-exception-throw-in-promise.html:
* inspector/debugger/break-on-exception.html:
* inspector/debugger/break-on-uncaught-exception-throw-in-promise.html:
* inspector/debugger/break-on-uncaught-exception.html:
* inspector/debugger/breakpoint-syntax-error-top-level.html:
* inspector/debugger/command-line-api-exception-expected.txt:
* inspector/debugger/command-line-api-exception-nested-catch.html:
* inspector/debugger/command-line-api-exception.html:
* inspector/debugger/csp-exceptions.html:
* inspector/debugger/didSampleProbe-multiple-probes.html:
* inspector/debugger/evaluateOnCallFrame-CommandLineAPI.html:
* inspector/debugger/evaluateOnCallFrame-errors.html:
* inspector/debugger/pause-reason-expected.txt:
* inspector/debugger/pause-reason.html:
* inspector/debugger/paused-scopes-expected.txt:
* inspector/debugger/paused-scopes.html:
* inspector/debugger/resources/exceptions.js:
* inspector/debugger/scriptParsed.html:
* inspector/debugger/sourceURL-repeated-identical-executions.html:
* inspector/debugger/sourceURLs.html:
* inspector/debugger/stepping/stepping-pause-in-inner-step-to-parent.html:
Canonical link: https://commits.webkit.org/182248@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@208523 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-11-10 06:07:07 +00:00
|
|
|
suite.addTestCase({
|
|
|
|
|
name: "PausedCallFrameScope.Complete",
|
|
|
|
|
test(resolve, reject) {
|
2017-08-02 03:09:57 +00:00
|
|
|
WI.debuggerManager.resume().then(resolve, reject);
|
Web Inspector: DebuggerManager.Event.Resumed introduces test flakiness
https://bugs.webkit.org/show_bug.cgi?id=161951
<rdar://problem/28295767>
Reviewed by Brian Burg.
Source/JavaScriptCore:
This removes an ambiguity in the protocol when stepping through
JavaScript. Previously, when paused and issuing a Debugger.step*
command the frontend would always receive a Debugger.resumed event and
then, maybe, a Debugger.paused event indicating we paused again (after
stepping). However, this ambiguity means that the frontend needs to
wait for a short period of time to determine if we really resumed
or not. And even still that decision may be incorrect if the step
takes a sufficiently long period of time.
The new approach removes this ambiguity. Now, in response to a
Debugger.step* command the backend MUST send a single Debugger.paused
event or Debugger.resumed event. Now the frontend knows that the
next Debugger event it receives after issuing the step command is
the result (stepped and paused, or stepped and resumed).
To make resuming consistent in all cases, a Debugger.resume command
will always respond with a Debugger.resumed event.
Finally, Debugger.continueToLocation is treated like a "big step"
in cases where we can resolve the location. If we can't resolve the
location it is treated as a resume, maintaining the old behavior.
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::stepOver):
(Inspector::InspectorDebuggerAgent::stepInto):
(Inspector::InspectorDebuggerAgent::stepOut):
(Inspector::InspectorDebuggerAgent::willStepAndMayBecomeIdle):
(Inspector::InspectorDebuggerAgent::didBecomeIdleAfterStepping):
When stepping register a VM exit observer so that we can issue
a Debugger.resumed event if the step caused us to exit the VM.
(Inspector::InspectorDebuggerAgent::resume):
Set a flag to issue a Debugger.resumed event once we break out
of the nested run loop.
(Inspector::InspectorDebuggerAgent::didPause):
We are issuing Debugger.paused so clear the state to indicate that
we no longer need to issue Debugger.resumed event, we have paused.
(Inspector::InspectorDebuggerAgent::didContinue):
Only issue the Debugger.resumed event if needed (explicitly asked
to resume).
(Inspector::InspectorDebuggerAgent::continueToLocation):
(Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState):
All places that do continueProgram should be audited. In error cases,
if we are paused and continue we should remember to send Debugger.resumed.
* inspector/protocol/Debugger.json:
Clarify in the protocol description the contract of these methods.
Source/WebCore:
Covered by existing tests that would ASSERT otherwise.
* inspector/InspectorClient.cpp:
(WebCore::InspectorClient::doDispatchMessageOnFrontendPage):
When paused on an exception in the inspected page and evaluating
commands in the inspector frontend page (which evaluates JavaScript)
we ASSERT when entering the Global DOM VM with an existing exception.
This makes it so when we evaluate JavaScript in the frontend we
suspend / ignore the state of the VM for the inspected page, and
restore it when we return from the inspector.
Source/WebInspectorUI:
* UserInterface/Controllers/DebuggerManager.js:
(WebInspector.DebuggerManager.prototype.debuggerDidResume):
Now, Debugger.resumed events really mean the debugger resumed,
so act immediately instead of guessing. We must still guess
in legacy backends.
* UserInterface/Test/Test.js:
When the inspector frontend encounters an issue, log it.
* UserInterface/Views/DebuggerSidebarPanel.js:
(WebInspector.DebuggerSidebarPanel.prototype._debuggerDidPause):
(WebInspector.DebuggerSidebarPanel.prototype._debuggerActiveCallFrameDidChange):
Always enable the step out button. I don't think it makes sense to disable
it sometimes, and if there are issues with this we should solve the issues
instead of hiding them.
LayoutTests:
Rewrite tests to be more deterministic. For tests that
relied on a Resumed event to happen after a short amount
of time, instead have the test dispatch an event when it is
appropriate to continue. Take this opportunity to rewrite
some tests using new style and best practices.
* inspector/debugger/break-in-constructor-before-super.html:
* inspector/debugger/break-on-exception-throw-in-promise.html:
* inspector/debugger/break-on-exception.html:
* inspector/debugger/break-on-uncaught-exception-throw-in-promise.html:
* inspector/debugger/break-on-uncaught-exception.html:
* inspector/debugger/breakpoint-syntax-error-top-level.html:
* inspector/debugger/command-line-api-exception-expected.txt:
* inspector/debugger/command-line-api-exception-nested-catch.html:
* inspector/debugger/command-line-api-exception.html:
* inspector/debugger/csp-exceptions.html:
* inspector/debugger/didSampleProbe-multiple-probes.html:
* inspector/debugger/evaluateOnCallFrame-CommandLineAPI.html:
* inspector/debugger/evaluateOnCallFrame-errors.html:
* inspector/debugger/pause-reason-expected.txt:
* inspector/debugger/pause-reason.html:
* inspector/debugger/paused-scopes-expected.txt:
* inspector/debugger/paused-scopes.html:
* inspector/debugger/resources/exceptions.js:
* inspector/debugger/scriptParsed.html:
* inspector/debugger/sourceURL-repeated-identical-executions.html:
* inspector/debugger/sourceURLs.html:
* inspector/debugger/stepping/stepping-pause-in-inner-step-to-parent.html:
Canonical link: https://commits.webkit.org/182248@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@208523 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-11-10 06:07:07 +00:00
|
|
|
}
|
|
|
|
|
});
|
|
|
|
|
|
2016-09-17 03:53:29 +00:00
|
|
|
suite.runTestCasesAndFinish();
|
|
|
|
|
}
|
|
|
|
|
</script>
|
|
|
|
|
</head>
|
|
|
|
|
<body onload="runTest()">
|
|
|
|
|
<p>Check scope chains for different call frames at different pauses.</p>
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|