Timestamps in console messages -- would anyone like this feature?

[Ivan Žužak]

Hey everyone,

I’ve been playing with the Web Inspector source code and working on adding timestamps to console messages. It’s something I've found useful in some situations (Firefox devtools have these also).

You can view the attached image to see how it would basically look like. There would also be a nifty on/off switch to control timestamp visibility.

Anyway, does anyone else consider this feature useful and would like to see it in Chrome dev tools? If so, I’d consider putting some more hours into it and submitting a patch to WebKit. You can also star the related chromium issue here: https://code.google.com/p/chromium/issues/detail?id=169734

Cheers,
Ivan

[Pavel Feldman]

Looks useful! Please follow the WebKit contribution guidelines and we'll review it there. Note the the timestamps will need to originate from the backend, i.e. you'll need to modify native ConsoleMessage.cpp and add it into the remote debugging protocol (Inspector.json).

Regards
Pavel

--
You received this message because you are subscribed to the Google Groups "Google Chrome Developer Tools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-develo...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Paul Irish]

Hey Ivan! Great to see you first in London and now here, in the inspector source.

I'm a little hesitant on this feature and think it dirties up the console quite a bit. 

What are some good use cases that this helps address? In the cases in my head I'm thinking better association with the log() call sites and perhaps pointing out the time delta between logs may be better solutions... but I'm not sure.

Regardless, happy to have you trying this out.. I've seen a few people wondering about it.

[Ivan Žužak]

Thanks for the pointers, Pavel! I have to admit I completely forgot about the debugging protocol, and also made the current version of timestamps only with frontend changes. But the backend changes don't look too frightening.

Anyway, looking forward to making a patch request eventually, after gathering a bit more feedback and compiling WebKit :). 

Cheers,

Ivan

[Ivan Žužak]

Hey Paul -- great to meet you in London, too. Your demo is still my favorite part of the conference :). 

As for the timestamp feature -- great feedback! And, what can I say -- I agree with you. It does dirty up the console with info that most developers don't need in most situation. I'm hoping that this (the visual noise) could be somewhat alleviated through better visual styling of the timestamps (by someone with a better sense of UX design). Also, the feature would be turned off by default and there would be a toggle button or an option in settings to show/hide the timestamps. 

My personal use case are complex Web apps and JS libraries that include timed actions, e.g. using setTimeout/setInterval. A few years back I was developing a library for RPC communication between iframes, windows and web workers, and this included a method for retrying a RPC call if it didn't succeed (using a backoff algorithm). In a typical webapp that used the library - there were dozens of iframes and the interactions were non trivial to debug (even with logging statements), since they were mutually dependent and also timed. The usefulness of log timestamps in such situations was to a) be sure when the timed actions were actually happening, and b) to disable the grouping of same-text log messages into a single message with a counter (to have a better view of all the events). 

As for other use cases for timestamps - I was hoping other devs on this list would have some :). I guess I like seeing timestamps when I'm trying to get a feeling of the dynamics of the interactions (based on log messages). It could also be useful for creating a dump file of the console contents, for archiving or sharing with someone (there's another feature request!).

I'm glad you mentioned better association with log() call sites -- because that's also one of the things I've been thinking about, for the same use case above. When there are multiple iframes in the same window, and more than one are creating log messages (sometimes with the same text!) -- it's a pain to understand who logged what. So, it would be useful to have some kind of identification of iframes/windows and to show such identification alongside log messages. Currently, you only see the name of the JS file that was executing when the log message created, but multiple iframe contexts could have loaded the same JS file. So, for example, showing the DOM id or name attribute of the iframe in the parent document would be helpful.

Deltas I haven't thought of... Still thinking it over. My first reaction was -- deltas will be useful sometimes, but most devs will be used to timestamps (imo), and adding up deltas to compute the timespan between two distanced log messages might get tiresome (15ms+37ms+119ms+62ms = ... ?). But since you can go from deltas to timestamps and back, this could be just another way of presenting the same timing information (off <-> on-timestamp <-> on-delta).

Thanks again for the support and feedback! 

[mar...@scriven.org]

Would really love to see this option - it's really good to be able to time events just by comparing timestamps. As you say, Firefox has this, would be a great addition to Chrome.

[alen...@gmail.com]

I would love to see this feature too!
When using setTimeouts dependent on each other to set of chains of events it can become messy when reading the log, a time stamp can really help make sense of it. Also when doing operations that take "long" it would be great to have a slight indicator of just how long it was, without making a whole benchmark testcase for it.

Keep up the awesome works, looks great!

[jason...@gmail.com]

I would like timestamps on my Chrome console warnings and errors.

[mgrif...@gmail.com]

Personally, I would like to see this in 2 situation:

1. off by default, with the ability to turn it on.

2. on hover of an event, it would be nice to see a timestamp

Numerous situations lead to the same error/log/warning/whatever being displayed in the console, and Chrome/WebKit does a great job of grouping these together.  I think that needs to be considered too, perhaps still doing this (as I think it's a great feature), but only showing the latest timestamp until the messages are expanded.

Great work :)