Console log output and events feature request

[valtido]

Hi,

I would like to request for a couple features, on request we should have a method that can output everything console has recorded so far like a stack list.

This is useful when you need to save it programmatically rather than debugging manually.

I would also like an event listener, so we can assign a handler and do something when there is a new entry on log, warn, error etc. Again for the same reason.

[zspitzer]

like a console.read(100); where 100 is the max number of lines to return?

[valtido]

Yeah sure, but this doesn't work at the moment, and also could be console.on("all,error,log,warning...", callback)

Or promise instead of callback. :)

Cheers

[domfarolino]

Seems like a good idea. Some points:

1.) I think we definitely wouldn't want a promise for this sort of thing. Sounds like you'd like to extend addEventListener to console? Like console.addEventListener('warn', e => {...}) kind of? I think that could be useful. Promises don't really fit this sort of behavior IMO.

2.) IIRC as @terinjokes pointed out to me the other day in person, callbacks should only be triggered for events originating from scripts whose errors are not muted for security.

Edit:

And furthermore, if 2.) is valid, something like console.read(...) (or whatever it might be named) should only store and return messages logged from scripts whose errors are not muted as well. With that being said, if we do go on with the implementation of this, maybe it might be worth looking into renaming muted errors in the HTML spec to muted output or something that covers more bases, since we might extend it to functionality in this spec?

[terinjokes]

We've defined an interface in this specification. I think there's more benefit to being able to pass an implementation of that interface (which might be this Console, or something created at runtime) to the library, rather than adding and requiring eventing supporting to all console implementations.

[zspitzer]

would console.read() also include the script source? i.e. "some message" app.js:45

[domfarolino]

I agree with @terinjokes on this, and I think there's more benefit to being able to build a mechanism that can do some sort of tracking when console methods are called as opposed to build that in here. This is mostly because it is only application code that calls the console methods, so application code authors (devs) should be able to easily track when these methods are being called.

It may be useful however, to be alerted when warnings are reported to the console (see #57), I guess it'd be worth polling implementers there, but I'm not sure.

Regarding console.read, there might be benefit to storing and having access to previous console output, but I think I'd need a more compelling use-case than web-platform-tests/wpt#8654 (testing). As discussed a bit in #75, there is some use but most of it isn't terribly productive so for now I'm kind of against it.