Thank you for the feature request!

To be clear, when you say you go through edit > rebuild > rerun > cleanup, it sounds to me like
- adding console.log()'s to the code in your editor, rebuild
- go back to Chrome, refresh the tab
- check the console output is correct, console.log()'s are no longer needed
- go back to editor, remove console.log()'s

Please let me know if I'm interpreting your use case incorrectly.

You mentioned that you are working on timing issues, so I'm guessing that the state you want to debug isn't simple to enter consistently, so typing 'console.log(...)' in the console isn't always possible?  If so, could you please elaborate on what's happening?  Is there a line to break on, but placing a breakpoint would trigger too many times?  It would help us to better understand your use case and why breakpoints currently aren't helpful in your situation.


You may already know this, but DevTools has a conditional breakpoints feature.  It allows you to type an expression that gets run whenever a line is encountered, and it pauses the debugger when that expression is true.
https://developers.google.com/web/tools/chrome-devtools/javascript/add-breakpoints#make_a_line_number_breakpoint_conditional

It's actually possible to enter 'console.log(...)' as part of the expression in a conditional breakpoint, and doing so will let you make console.log() calls without editing the JS source code.  Does that help in your situation?

Hi Luoe, thanks for the response & the tip.

I had not experimented with the expressions that I could enter into conditional breakpoints and whether they would execute.  Plus I had not investigated all of the console methods (so I was unaware that there were methods that would dump a stack trace too, e.g. trace, warn or error.) [basically I was ignorant :-)]

To make what I want happen I enter into the conditional breakpoint:
"console.trace('message')"
or console.warn() or console.error()

1. it does not break at the line (because I assume the result of console.trace is undefined.)
2. console.trace will include a stack trace so I can trace where this is called.

&& I can do conditional output with a little logic, e.g.:
"if(expression) {console.trace('message')}

This is great!! and it meets my needs almost perfectly.

I can only think of 3 benefits to creating an output type like I described:
a. able to enter the 'message' without entering console.log call.
  - this is a nice to have at best

b. able to manage the outputs separately from managing the debug lines.
  - this might be more interesting.  For example, many times I want to disable all breakpoints but I would like my console statements to continue.  This may be a little tough to manage for complex cases.  This could be improved by designating conditional breakpoints differently in the "breakpoints" pane.  For example, you could color conditional breakpoints a little bit and maybe display the condition of the breakpoint (that way it would be easier for me to see and manage).  Today I only see a snippet of the line where the breakpoint is set.

c. I assume that many users may not be aware of this capability that is really tremendous.  So making it more discoverable may improve developers lives.
  - this may be the best reason to do the feature.

At the very least it may be useful to update these 3 articles with the insight that console output can be created on a line via the conditional breakpoint:
https://developers.google.com/web/tools/chrome-devtools/console/console-write
https://developers.google.com/web/tools/chrome-devtools/console/
https://developers.google.com/web/tools/chrome-devtools/javascript/add-breakpoints

I did a couple of searches on this concept and I did not find any blog posts anywhere that may have explained this idea.

Glad you found something that worked!  Another way that might work is to put the console.log/trace/warn in a Watch expression.  Each time it stops on a breakpoint, the watch should execute.

@chowse: I think the OP has a valid use case here, wanting to add and remove console.logs without having to edit the code.  It's really not obvious to putting console.log in a watch expression/conditional breakpoint actually executes them.  Maybe as part of the help project we can use heuristics (such as detecting when an expression is repeatedly evaluated in the console) and suggest watch expressions?

If we want to adopt this kind of functionality natively, we probably want to approach it like Safari/WebKitNightly's Breakpoint Actions and Probe Expressions (https://webkit.org/blog/5435/breakpoint-options/). Adding console actions to the breakpoint condition is counterintuitive and something we don't want to encourage.

Thanks for considering this.

My feedback is that it would be OK to combine with breakpoints.  But, a key feature would be to make it easy to manage them separately.  The example I think of is that if I have ~5-6 console.log's in there and I want them to stay on.  Plus I have 5-6 breakpoints.  I want to deactivate all the breakpoints easily without having to examine breakpoint line (which is what I have to do today).  So running with the webkit spec, I would have an option to deactivate all breakpoints, all breakpoints that are only console.log, all breakpoints that are not console.log, etc.  But that might be a little clumsy.  It may be appropriate to introduce this concept as completely separate from breakpoints.  Underneath it could be based on breakpoints but the user interface is streamlined for console output.

Another problem for both breakpoints and this feature is when code is added to the source and all the breakpoints / console.log items are keyed to previous line numbers.  I have not used in-place editing (maybe it handles this) but I am imagining that on reload a simple diff could be performed on the old and new code load to determine where to move the breakpoints to in the new file. (maybe that is another feature, but for the console.log thing to work, it would be great to solve this)

Again, thanks for listening.

cc'ing chenwilliam@

To give an update: there isn't yet a firm plan on the right UX, we are still exploring.

Our solution to this is console.log in a conditional breakpoint atm.

Thanks for considering this.  I get/understand you setting this to “wont fix”.

 

Only thought is for certain timing bugs having better control over console output would be a pretty big boost.  I assume timing bugs are probably a type of bug that occurs much less often, but the debug of them can be quite manual.

 

From: pfeld… via monorail [mailto:monorail+v2.2946796515@chromium.org] 
Sent: Friday, December 8, 2017 12:09 PM
To: brucejo75@gmail.com
Subject:  Issue 666953  in chromium: DevTools: make console log/traces easy to add/remove at breakpoints