Provide special targets to set breakpoint against.
-- 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
Yury, I'd like to separately address the feature priority question and its
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
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
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.
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
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
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
that not always user can (or want to) modify his program. So I planned this
feature with the similar assumptions.