Reporter@ - Thanks for filing the issue...!!

Could you please provide a test file with consistent reproducible steps to test the issue from TE-end.
This will help us in triaging the issue further.

Thanks...!!

Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Here is the test page source code:

https://gist.github.com/kirkouimet/1e3dea6b5ead49e282c5b6949324e8f8

And rendered version:

https://rawgit.com/kirkouimet/1e3dea6b5ead49e282c5b6949324e8f8/raw/396ccf46a6634b870acc15db7af60698759e67e5/779244.html

Thanks for the report, OP.  It looks like commenters in the bugs you've linked also believe that blackboxing a file is too aggressive of a solution, since it affects more than what you intend (just the custom logger).

To address your points,
> 1. It's easy to forget to configure this setting and update it per project
I agree that it's not very clear when/which files are blackboxed from the UI.  We should try to make this easier to setup and more clear when it is applied.

Blackboxing does require work to setup, so perhaps there is an opportunity to extend the Console API for this, as you suggest.  However, I would like to see if we can improve blackboxing first.  We might only want to hide the top callframe from the trace today, but modifying other callframes might be useful in other cases that we could support with a new API.

> 2. If the blackboxed file has other logic in it which we wish to log, we cannot easily log it
I see!  We need something that doesn't interfere with the rest of the file.  Perhaps an easy "function-level blackboxing" is what we need?  kozy@, would this be possible?

cc'ing kozy@ who may already have ideas and thoughts in this space.


As a side note, I don't use custom loggers myself, and I wonder what your use case is for wrapping console.log.  Is it to add a prefix to the message?  If we understand the use case, maybe we have other ways to support them, too :)

Thanks for the reply on Comment 6.

My main goals right now are:

1. Special formatting and additional information added to things being logged (manipulating the arguments before they hit the log)
2. Logging things to disk into a log file (when using Electron where node.js has access to the system disk)

Best,

Kirk

You need to blackbox customLog() and things would work as you expect.

Hi pfeldman,

Can we reopen this issue? Blackboxing does not seem like the best solution, you can see with my discussion with kozy@chromium.org:

---

One solution to this problem is using the Developer Tools blackboxing approach which is to suppress all stack frames from log.js. The problems with this approach are:

1. It's easy to forget to configure this setting and update it per project
2. If the blackboxed file has other logic in it which we wish to log, we cannot easily log it

This guy had a great idea of being able to specify transparent stack frames as a formatting option, and being able to specify how many frames to skip:

https://bugs.chromium.org/p/chromium/issues/detail?id=231007#c19

Another approach is to create a new function on the global console object to enable this behavior.

I don't think this issue is a duplicate of the other issues as they have been closed out in favor of the blackboxing method. If there is not consensus on blackboxing being the right way to do it, we should leave this ticket open and explore implementing an alternative method.

---

Best,

Kirk