Summary: Debugger should resume immediately while under test. DebuggerManager delays updating state and firing events when the debugger resumes, to prevent spamming user interface updates while stepping. Unfortunately this causes timeouts in layout tests that try to pause/resume the debugger rapidly. DebuggerManager should only introduce a delay if not under test. This can be easily tested using setInterval: InspectorTest.evaluateInPage("setInterval(() => { debugger; }, 0)"); let repeatCount = 5; WebInspector.debuggerManager.addEventListener(WebInspector.DebuggerManager.Event.Paused, (event) => { WebInspector.debuggerManager.resume(); if (--repeatCount) return; resolve(); }); If the test finishes, it passes.
<rdar://problem/29132915>
Created attachment 294041 [details] Patch
Comment on attachment 294041 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=294041&action=review > Source/WebInspectorUI/UserInterface/Controllers/DebuggerManager.js:618 > + // It isn't necessary to delay firing events when under test. > + if (window.InspectorTest) { > + this._didResumeInternal(target); > + return; > + } While I agree with the problem, I'm not sure this is the right solution. Wouldn't this mean that step-in commands get a Resume + Pause immediately? I would have only expected a CallFramesDidChange. In fact, doesn't this break all of the inspector/debugger/stepping tests? (Marked as flakey on the bots, so `run-webkit-tests inspector/debugger/stepping --force --v`( See my lengthy comment on https://bugs.webkit.org/show_bug.cgi?id=164305#c2 where I describe what I think would be a better fix. The problem is the frontend currently does not know if a step will end up pausing or resuming, so it sets a timeout to assume resume. If we eliminate this ambiguity then the frontend can know for certain what events it should fire as a result of stepping or resuming by the user. The one potential hiccup would be clicking resume could flash the UI if we resume the UI and then immediately pause on another breakpoint or something. That said, it would till offer advantages over what we have today. Basically the events I'd like to see when pausing, stepping a few times, and resuming would be: Paused + CallFramesDidChange CallFramesDidChange CallFramesDidChange CallFramesDidChange Resumed + CallFramesDidChange Not: Paused + CallFramesDidChange Resumed + CallFramesDidChange Paused + CallFramesDidChange Resumed + CallFramesDidChange Paused + CallFramesDidChange Resumed + CallFramesDidChange Paused + CallFramesDidChange Resumed + CallFramesDidChange which I believe is what this would produce.
This is a duplicate of bug 161951. Perhaps we should move to that. *** This bug has been marked as a duplicate of bug 161951 ***