Brian Grinstead

I have been working on a small collection of snippets that are handy to reuse inside of browser devtools. These can be used in any devtools. You can jump straight to the devtools snippets project page and readme if you want to see some screenshots and details about each individual snippet.

The actual snippets can be seen here: https://github.com/bgrins/devtools-snippets/tree/master/snippets

Why would you use snippets

A common usage for snippets is to replace developer bookmarklet type of functionality. The problem with bookmarklets is that they are a pain to create and share, and even using them can be difficult. You may need to show a bookmarks bar in the UI, run it, and open up devtools to see if it worked. Then you would need to make changes to a giant single line of JavaScript inside of a bookmark manager, or use a generator to convert a .js file into a bookmarklet. Snippets are a much better way to handle this workflow. Examples of this type of snippet would be adding jQuery to a page without it or printing the HTTP headers from the current page.

Another use would be saving console commands that you use during development. For example, if you wrote something to help export information from a page, or print out some debugging data for your application you can just use the multiline snippet editing interface rather than typing in the console, and save it when you are done in case you need it later.

Browser Support

Firefox has multiline support using the scratchpad editor, and Chrome has a new ‘snippets’ feature.

Currently, in Chrome you have to enable snippets support in chrome://flags and inside of devtools settings (see full instructions and screenshots). They are enabled by default in Canary, so this feature set will soon be widely available.

Firefox Scratchpad is really cool for experimenting with code, though I would like to see better management of snippets (‘scratches’?). For example, see the UI for snippet editing in Chrome:

Future Functionality

Things that would be awesome to add:

• Firefox: Better management of snippets. As seen in the screenshot above, it can be really handy to have a UI for storing, editing, and saving changes to the snippets. To be fair, right now you can save scratchpad contents to a file and then ‘open’ or ‘open recent’ later. Maybe if this was pulled more prominently into the UI without needing to open up a file explorer that be enough. It is cool that it actually saves the files to a known place on your disk.
• Chrome: Keyboard shortcut to run a snippet (or part of a snippet). Scratchpad uses Cmd+R/Ctrl+R, which makes sense. Also, storing the snippets in a known place on the disk is really handy, as they could be backed up, copied directly into a project, etc.
• All devtools: Import / export snippets. You can then sync your snippets across computers or share them with others. Maybe some sort of zip or JSON file containing the contents of all the snippets. Or a maybe a URL importer that loads the response into a new snippet, named the path of the request by default. For example, pasting https://raw.github.com/bgrins/devtools-snippets/master/snippets/performance.js would create a new snippet called performance.js with the contents of that request. Then you could just load up the importer with a list of URLs:

   
  https://raw.github.com/bgrins/devtools-snippets/master/snippets/performance.js
  https://raw.github.com/bgrins/devtools-snippets/master/snippets/log.js
  https://raw.github.com/bgrins/devtools-snippets/master/snippets/base64.js
  ...

Snippets inside of devtools are big timesavers and are going to be really helpful for a lot of developers. You should check them out if you haven’t yet. Going forward, I’m hoping there will be an easy way to use, manage, and discover new snippets that work across browsers.

I have often found it tricky to get a ‘just-right’ console.log wrapper in JavaScript. I would prefer to just type log, but writing a wrapper function is a little trickier than at first glance. A variation of this used to exist in the HTML5 Boilerplate plugin.js but is now missing.

I have two versions – one is bigger, and is intended for an application – it stubs out console methods when they don’t exist, and exposes a log function to the window. The second is portable – it is meant for use inside of plugins.

The neat thing about this technique is that this preserves the original line of code inside of the console.log statement, rather than the line in which the log function is declared.

The code is in a gist, which is also embedded below:

I’m still trying to figure out how to get a list of all the colors in use on a page from within devtools, but I’ve been hacking together a little demo with a custom Web Inspector frontend that loads a color palette on the side.

When you click one of the swatches, it sets the current color of the element. The idea is that it would include all the colors in your page, maybe ordered by most used. Possibly could even get more advanced and suggest a set of complementary or analagous colors based on your current selection.

A prototype implementation of a palette using color swatches within devtools

jsbin has made having to remember some of these links less important. However, with jQuery UI 1.9 coming out, there are some CDN links that aren’t working. Here is the updated boilerplate I use to quickly test out a jQuery UI project. If all goes well, you should have a dialog that you can drag around and resize.

<!doctype html>
<html>
<head>
  <title></title>
 
  <link rel="stylesheet" href="http://code.jquery.com/ui/1.9.0/themes/base/jquery-ui.css">
 
  <script type="text/javascript" src="http://code.jquery.com/jquery-1.8.2.js"></script>
  <script src="http://ajax.aspnetcdn.com/ajax/jquery.ui/1.9.0/jquery-ui.js" type="text/javascript"></script>
 
  <style type="text/css">
    #modal {
	 background: orange;
    }
  </style>
 
  <script type='text/javascript'>
    $(function() {
        $("#modal").dialog({ title: "It works" })
    });
  </script>
</head>
 
<body>
<div id='modal'>jQuery UI!</div>
</body>
 
</html>

As a bonus, here is the markup in jsbin.

Sometimes I just want to see all (or many) of the variables inside of the function, and it can be a bit of work to copy all of the variables into the console.log() call when you know that you are just going to delete the line afterwards anyway.

It would be great to have a console function that handles this. It would be called console.scope. When you call console.scope() it would act similarly to console.trace(), except instead of seeing the call stack in the console, you would see the same thing that you see in the ‘Scope Variables’ panel when inside a breakpoint in the Sources Panel (see images).

I have also opened a thread about this on the devtools mailing list.

I have published my TinyColor package to the npm repository – https://npmjs.org/package/tinycolor2. Unfortunately it is called tinycolor2 since tinycolor was already taken.

After running

npm install tinycolor2

You can use tinycolor like so:

var tinycolor = require("./tinycolor");
console.log(tinycolor("red").toHex());

See the project homepage or the README for more info.

It is great that so many important platforms that we use on the web are open source, and open to contributions from anyone.

It took a lot of work, but it was worth it. I’ve been doing some web design work recently, and love how much easier it is to play with different colors in a design.

Now I’m thinking of different ways that design work could be further improved with the colorpicker. A couple of ideas right now: (a) an eyedropper to select a color from the screen and (b) a color palette consisting of currently used and recommended colors.

I was asked a question in my DevTools talk at ComoRichWeb this month.

Q: How do the event listeners work when the events are bound with jQuery?

A: Not well. I rarely use that section when using a framework to bind events, because the event listeners never point back to the actual function being bound – instead they link to the jQuery source.

The info you see on event listeners bound with jQuery is not very useful. It shows you the actual function where the events were bound (which is inside of the jQuery source).

Open up this simple event listener test case in devtools (inspect the button and view event listeners) to see what I mean.

What Information Do You Want From Event Listeners?

What I am actually interested in is the actual callback that jQuery is adding. Of course devtools shouldn’t have to handle jQuery (or other frameworks) specifically, but what if it showed the callstack that caused the event to be bound?

So, by setting a breakpoint to the actual event event binding, here is what I got. This is what I am actually interested in:

Solution?

And putting my photo editing skills to the test, here is what it could look like (of course, this should be styled consistently). Clicking on one of the entries in the callstack would take you into the relevant place in the scripts panel.

This would be ideal. Is this even possible? Or there is an existing or better way to get around this that I don’t know about?

I presented on using Chrome Developer Tools at ComoRichWeb, a web developer user group in Columbia, MO on June 20th. Here are the slides and some other links:

Slides and Demo

• DevTools, Part II Slides
• Color picking demo to play around with devtools

Other Links Mentioned in the Talk

• Source Maps Article
• Remote Debugging on Android (apparently also coming to iOS 6)
• Devtools Documentation
• log() function wrapper from HTML5 Boilerplate

We had a good turnout last night, was glad to get a chance to share some front-end development tips with local developers.

I have been working on updating the FileReader.js JavaScript file reading library lately to help out with a few different projects. This library has provided a quick way to get started with reading files on a few different projects, like mothereffinganimatedgif.com and Instant Sprite.

One thing I noticed was that there is a FileReaderSync API, meant for loading files synchronously.

You might wonder why on earth would you want to load a file synchronously in your browser – that seems like it could block the entire UI until the file is loaded! It turns out you can’t, at least not in the normal window context. FileReaderSync only exists inside of the context of a WebWorker:

Implementation

View a A working JS Fiddle using FileReaderSync.

I also wrote about how to load web workers without a JavaScript file, but this technique works just fine using a normal external reference.

markup

<input type='file' id='files' multiple onchange='handleFileSelect()' />

page javascript

function processFiles(files, cb) {
    var syncWorker = new Worker('worker.js');
    syncWorker.onmessage = function(e) {
        cb(e.data.result);
    };
 
    Array.prototype.forEach.call(files, function(file) {
        syncWorker.postMessage(file);
    });
}
 
function handleFileSelect() {
    var files = document.getElementById('files').files;
    processFiles(files, function(src) {
        var img = new Image();
        img.src = src;
        document.body.appendChild(img);
    });
}

worker.js

self.addEventListener('message', function(e) { 
    var data=e.data; 
    try { 
        var reader = new FileReaderSync(); 
        postMessage({ 
            result: reader.readAsDataURL(data)
        });
   } catch(e){ 
        postMessage({ 
            result:'error'
        }); 
   } 
}, false);

The jsFiddle demo is a little more complicated than this, since it handles checking for support and an inline worker.

Gotchas

Something that was a little weird is that since you can’t detect support from the main window, I need to spawn off a worker to post the message of whether it supports FileReaderSync. See a jsFiddle to detect FileReaderSync support. There may be a better way to do this, but I don’t know of it.

This can be pretty complicated, but I have been tying it all into the filereader.js plugin, to make reading with FileReaderSync just an option along with the standard FileReader

Performance

It’s hard for me to accurately measure the performance. On one hand, the FileReaderSync seems to load the images in a slower time per image (measured in milliseconds). I assume that this is due to the overhead and message passing with the worker, or possibly because it is a newer implementation.

However, on large images and videos, it definitely feels like the UI does not lock up as much when processing the files.

Purpose

I feel like maybe part of the point of this API is when you want to some heavy lifting with the file after it is loaded but still inside the worker, which isn’t currently supported in FileReader.js. I could imagine ways this use case could be supported though (maybe by passing in a process() function as a string that the worker could call?

Check out the FileReader.js demo and see if you can tell a difference! I’d love to get any kinks worked out and get some feedback – I have been thinking of setting up a js-file-boilerplate project on Github to tie together a bunch of this functionality in a sample project.