Provide special targets to set breakpoint against.
For example:
-- script has been parsed,
-- exception is being thrown,
Allow embedders to extend the list:
-- page is being navigated away,
-- console.log is called,
-- console application is finishing.
User should be able to create (multiple) breakpoints against these targets.
Breakpoints should support condition expressions that are evaluated in a
special context, filled with event parameters. The event parameters, such
as exception value or script text are required to let user filter out
non-interesting cases. This additional scope must also be visible in
debugger.
We already have pause-on-exception functionality and given that there are
usually not too much exceptions in normal case I don't think there is a
demand for adding condition to the pause-on-exception.
Can you elaborate on "script parsed" breakpoint and when it can be useful?
I can think of evals and dynamic scripts where it would be similar to pause
on the first statement in the eval'ed script.
It seems that all of the mentioned embedder's breakpoints can be simulated
using existing JS/browser APIs.
Btw, shouldn't this bug be filed against Chromium instead of V8 (v8 already
provides ScriptParsed event as well as Exception even)?
Yury, I'd like to separately address the feature priority question and its
technical aspects.
On technical aspects here:
Script parsed event might be a good technique when you need to debug a
dynamically-loaded script with a poor name scheme – by having a breakpoint
with condition against script text you can efficiently filter out noise
scripts.
As to embedder events that could be simulated by JS/browser API, you assume
that browser is the only possible embedder. However, there are others (see
console appilcation use-case above), that would normally use Debug Agent
and have no actual communication with the remote debugger.
As to ScriptParsed event, it doesn't seem sufficient. First of all, for
Debug Agent it's asynchronous and cannot be used to make any required
preparations. Secondly, in Chromium approach you would need to handle
condition evaluation yourself, differently from what is done for
breakpoints. And again, even though ScriptParsed is synchronous for
Chromium, I'm not sure how far the callback is supposed to do arbitrary
processing, such as calling user JavaScript code (conditions).
speaking about feature priority, I admit it's unclear.
However, when asking my colleagues, one of them told me that he'd love to
filter exceptions by their type – an example how breakpoint conditions
could help.
The user-reported Chromium bug asks for pausing on post-script-compile
event.
This bug is just a logical closure of those and similar requests.
Doesn't Debug.DebugEvent (debug-debugger.js) in the javascript API solve
this problem? The debug listener is fired on any of the events listed
there, and the list can be extended to include something like ScriptParsed
Then again, I don't see the immediate need for this. If I understood
correctly, then the easiest workaround to break on script load is to prefix
every script with a call to a function that has a break point set.
Yang,
Debug.DebugEvent has its shortcomings. I want a full breakpoint semantics
and that's what's missing now:
- complete execution state (normal access to debug call stack)
- user condition expressions (an expression that is calculated in a special
scope with event parameters)
- DebugAgent protocol support. Someone who connects to V8 with DebugAgent
(e.g. Node.JS) does not have a direct access to javascript API. It will
only receive asynchronous notifications via protocol, as far as I
understand. Instead, user condition should be checked and if positive, the
full debug pause should be established.
As to immediate need, I meant this bug more like a roadmap – my view how we
could provide a consistent and feature-rich model for similar needs. I
didn't mean an immediate need, probably I should have written it more
explicit.
However, I think the workaround you are suggesting may not entirely fit
into debugger philosophy: basically you suggest user to modify his program.
But for example do one ever need conditional breakpoints with this
approach? I want to say that our JavaScript debugger tools clearly assume
that not always user can (or want to) modify his program. So I planned this
feature with the similar assumptions.
