[Webkit-unassigned] [Bug 143225] Web Inspector: debugger pause reason not updated when paused at breakpoint after resuming from debugger statement

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sun Jun 5 15:36:42 PDT 2016


https://bugs.webkit.org/show_bug.cgi?id=143225

Brian Burg <bburg at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bburg at apple.com
            Summary|Web Inspector: debugger     |Web Inspector: debugger
                   |pause reason not updated    |pause reason not updated
                   |when stepping after initial |when paused at breakpoint
                   |pause                       |after resuming from
                   |                            |debugger statement

--- Comment #4 from Brian Burg <bburg at apple.com> ---
I hit this again yesterday. It's really awkward if you continue from a debugger statement in one file, then you hit a breakpoint deep in some other code and the Pause Reason still says "Debugger Statement".

I think the current behavior w.r.t. what should be shown after stepping is fine, and I disagree with my initial bug report here. However, the behavior when hitting a breakpoint after resuming from another breakpoint/debugger statement/immediate pause is jarring and hard to argue in favor of, IMO. We probably need to distinguish these different types of pauses in the frontend, since IIRC it counts everything as being part of the same "paused session" if the debugger re-pauses within 50ms or some other arbitrary time limit.

New STEPS TO REPRODUCE:

1. Inspect the attached test case, enable breakpoints
2. Set a breakpoint on `window.dispatchEvent(e)`
3. Reload the page
4. Hit continue when the debugger pauses at the `debugger` statement

EXPECTED:

Pause Reason is updated to cite the breakpoint from step (2)

ACTUAL:

Pause Reason still cites the debugger statement

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160605/1f963fdb/attachment.html>


More information about the webkit-unassigned mailing list