search

whatwg / console

Console Standard
https://console.spec.whatwg.org/
Other
269 stars 67 forks source link

window.onconsoleopen Event #176

Closed jabcreations closed 4 years ago

jabcreations commented 4 years ago

I'm the lead developer of a web platform and I have to review JavaScript errors fairly often. Some of the sites utilizing my software are highly technical and often users will open the console and start to test their own code which typically triggers an error and gets logged in to my system for review. Since my system is rather unique it's moderately easy for me to tell if an error in the system's JavaScript error log is a native issue or if someone decided to mess around.

It would be exceptionally useful to have a simple window.onconsoleopen event. By testing if the console has been opened we can either mark errors as potential third party scripts or outright disregard them.

Since sites can still encounter native errors when another developer or technically inclined visitor is messing around in the console a window.onconsoleclose event would make sense to allow a site to know that the console is not open. While it would be possible for someone to add JavaScript to a page and trigger an error after closing the console their session could be marked as having had the console open at all granting greater debugging insight for webmasters.

JoelEinbinder commented 4 years ago

To add another perspective. Detecting the browser console can be a security vulnerability. A malicious site could turn off its malicious behavior when the console was detected in order to hide itself.

What if the error stacks had the console prompt named in them?

jabcreations commented 4 years ago

Did you know that by existing that you yourself could be physically stolen? If you're not going to attempt to address the issues you brought up then you're only being obstinate to those who require this ability.

terinjokes commented 4 years ago

It is common for exceptions to come from many aspects of the user agent: extensions, userscripts, experimental browser features, third-party scripts, and the console. Many exception reporting tools already support filtering exceptions that originate from these areas. Does filtering not work in your use case?

The console is a debugging tool. Allowing it to be observable by the page being observed simply be being opened, which we've tried very hard to avoid, can easily lead to subtle and difficult to track down bugs. I still remember trying to track down bugs in a browser that (accidentally) differed how timers fired depending on if the developer tools had ever been opened in that browsing session.

This specification doesn't define the user interface for a console. It doesn't make sense for us to specify how agents implement their console UI. In addition to the common UI in the browser, some agents always have a console available, and others make it available as part of a network protocol. It's not clear what a "consoleopen" event would mean in these agents.

domfarolino commented 4 years ago

I agree with Terin here, I don't think this is something we'd be willing to spec. We want the existence of something like DevTools or an inspector to be unobservable from application code, and also this seems to be difficult to reason about in an environment such as Node.js. I'll close this, but thanks for filing.