Console log output and events feature request about console HOT 6 OPEN

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?

from console.

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

from console.

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

from console.

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.

from console.

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

from console.

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.

from console.