Kartones Blog

Debugging with Google Chrome basics

Kartones — Thu, 09 Feb 2012 18:59:22 GMT

When Google created Chrome they had a few goals in mind, like having a powerful Javascript engine (the now famous V8), using the best browsing engine (WebKit) and even changing the typical version release flow so that we forget about browser versions and "just have the most recent one".

Clearly, one of them was to utterly destroy Firefox as a web developer tool, by providing with an all-in-one debugging suite. Without any external plugin (like Firefox and Firebug) you can develop or debug websites with ease.

General

The developer tools can be opened just by hitting F12. They are accessible from the menus too, but it's easier to just press the key. It opens on a per-tab basis, without sharing logs or network traffic analysis, and if you close the browser it won't reopen (unlike FFox's Firebug which remembers if it was open for a given domain).

By default the developer tools panel is docked to the bottom of the browser, but you can undock to a separate window if you want.

To avoid repeating the same a hundred times, whenever I say "edit" inside the dev tools panel, this has a lifespan of "until the next refresh". If you for example change some CSS, or remove an HTML, it will be reset if you click F5 or interact with the page in a manner that results in a refresh.

The console can be opened in most tabs too, but as it has its own I won't spend time explaining it until its time comes.

Also, all sections have a search bar at the top-right of the dev tools. This search is dependant (network traffic, DOM elements, script source code…) so remember that you can always search!

Elements section

In this view, at the left we have the HTML source view. We can easily navigate expanding and collapsing nodes, clicking on them shows at the bottom the tree hierarchy,

As you can see in the following screenshot, right-clicking on a node also allows you to do lots of interesting things, like watching DOM modifications or live editing attributes, the full node or even deleting it.

At the right side, we can see 6 tabs with a lot of info:

CSS styles: Both the computed total attributes, and a hierarchy of where each one comes from. We can also add, remove and modify more CSS. The Metrics tab displays a visual "map" of the item dimensions, margins, paddings…
Properties: Javascript object hierarchy of the selected node, displaying all attributes and going up to the top (to Object).
DOM breakpoints: Those defined with the right-click menu. We can disable or remove them from here.
Event Listeners: Another jewel. Displaying a list of all events attached to a given node, with some helpful properties and even the source code file and line number where it was attached from.

Resources section

This view allows to see data related with data storage.

The Frames node contains all data per frame of the tab: HTML source code, CSS stylesheets, script files and images.

The Cookies node contains all cookies fetched in the tab, and we can tamper with them or even delete them if we wish.

Local Storage and Session Storage display all Web Storage data with simple key/value lists. And we also have Application cache and Databases sections, although their use is more dependant of specific needs.

Network section

To use the Network panel, remember to either have the developer tools open before loading the page, or refreshing it, so that it can capture all requests.

This view provides realtime network traffic data, from the HTTP method used or response status, to the response type, size, latency, or even impressive details of the time spent:

All of this while being able to filter by type, search or even "preserve" (lock so that even after a refresh the list doesn't empties).

Scripts section

The Javascript source view. From here we can check all javascript, and by all I mean included JS files, script blocks (tagged "(program)" and by source HTML file), and external JS files (for example those loaded in an iframe).

We can filter per file, add watch expressions, check the call stack when we hit a breakpoint, see scope variables, and even debug worker threads.

Supported breakpoints are: DOM, XHR, Event listeners and "normal" ones (those added to javascript code lines).

And two (sadly exclusive) last things we can do are Pretty Print and Edit.
Pretty Print allows to format javascript code, easing the hell of debugging a minimized 1 line huge file.
Edit allows to directly modify the javascript code (awesome for trying a bugfix without re-deploying code!), but the caveat is that if you pretty-printed it you cannot edit.

Timeline section

This view serves as a nice Javascript helper. You just click record, and do whatever you want to analyze.

You will get all events, reflows/repaints/recalculations, and some non-JS events like resource loading (because they usually matter, but you can filter them out). It also shows a timeline of memory consumption.

As you can see in the following screenshot, the amount of details given for each event are great. In fact you can notice strange Chrome extension behaviours, like installing a timer for the AdBlock extension when I have the analyzed webpage whitelisted (and thus it should just be ignored).

Most events allow to unfold/expand them into even more detail (e.g.: before load event, function call to load resource, evaluate JS, evaluate context in which it was triggered to load…). As you might have noticed by now, this is almost like working with any other compiled language (remember that modern browsers actually compile Javascript instead of pure script parsing and execution).

Profiles section

Imagine you have a Javascript memory leak. Imagine you are not sure where to start looking for it, and you have lots of javascript. The Profiles view is your solution.

Click record, perform a few operations in a suspicious section, click again and there you have, a nice profiling report of what consumed most time (in absolute totals or real usage milliseconds).

But let's say some of the results appear ok, and you are handling for example mousemove or other events that generate many events, and yet is not the leaking problem.

Then the "eye" button allows to do a Heap snapshot. Click to take one snapshot. Do something in the page (for example if suspicious about a photo slideshow load a few photos), and click again to have a second snapshot.

Go to the second snapshot, and in the lower part of the bar select "Comparison", like in this screenshot:

Now we have a nice treelist of objects, functions and special structures (like closures), with number of items added, deleted, creation/deletion delta (difference between created and deleted, memory consumed, memory freed and memory consumption delta.

Again we can expand the nodes and see up to the point of each compiled array and its internal values.

And with just one snapsot you can check the shallow size (memory held by an object itself), retained size (total memory that will be freed when the object is is deleted), checking the heap, and the dominators (Garbage Collector-relevant hierarchy of objects).

Audit section

This section, along with the official Google's PageSpeed Chrome extension, allow to generate network and performance audits. While this audits won't cover all your possible site optimizations, they give general advices, specially regarding bandwidth, resource loading and caching.

It is worth to run it from time to time to check and improve some of the points it advices.

Console section

Well, up to this point, the only thing that remains to be able to do, is writing javascript code on the fly, no? And that's exactly what the Console does, allows both to write JS from scratch, or to operate with current page Javascript (calling JS functions, etc.).

It is context dependant, so if you setup a breakpoint you will have scope variables access, else you will have access to the global variables and objects, plus loaded javascripts.

It allows single or multi-line code, gives a really great output, and also serves to read and filter console.xxx() outputs.

Chrome's console is as powerful as Firebug's one, I've seen colleages writing full code blocks here due to the quickness of testing.

Bonus #1: Disabling the cache

Modern browsers tend to have very aggressive caches, and Chrome by far beats everyone else (I've noticed cache inconsistencies even between their own services, like Google+ profile photo and the avatar in the header bar of GMail). So the top #1 feature requested by every web developer was "how to clear or disable the browser cache".

Well, since a few versions, things can't be easier. At the lower right part of the developer tools there is a black gear icon, click it, and you will popup the settings, including the beloved "Disable cache" :)

Bonus #2: Modifying the User Agent String

From the same gear settings as in the disabling cache checkbox, just below it you can also override the user agent, very handy for initial testing of mobile versions, etc. You should always do testing with a proper emulator or real devices, but for the first stages is perfect and now you don't need any extension.

This has been just a basic introduction to Google debugging 101, if you want to deeply learn each option, I recommend you to read the Chrome Developer Tools documentation.

Note: At the time of writing this article, Chrome is at v17.0, just out from beta into the stable channel.

Debugging with Google Chrome basics was posted the 02/09/2012 at Kartones.Net.

Sharing buttons without Javascript

Kartones — Wed, 01 Feb 2012 23:56:00 GMT

One thing I'm maniac about is trying to have as less external javascripts as possible in my websites.

Because of this, the typical share buttons get me mad, as they usually have an associated javascript file, which does from not-so-async-rendering, to rendering an iframe, to even nasty cookie tracking (e.g. Facebook's Like).

Recently I finally found how to share in Google+ (specifically, doing a +1) without needing any javascript. I already had the other typical sharing button urls, so here is the small list of url-based sharing:

Twitter:
http://twitter.com/intent/tweet?url=XXXXX&text=YYYYY
Google+:
https://plusone.google.com/_/+1/confirm?url=XXXXX
Facebook:
https://www.facebook.com/sharer/sharer.php?u=XXXXX
Tuenti:
http://www.tuenti.com/share?url=XXXXX

Remember to always URL-encode the URL and text parameters.

PS: I know there are more but in general when I see a dozen buttons I ignore all of them so I'm leaving the minimum I want to have.

Sharing buttons without Javascript was posted the 02/02/2012 at Kartones.Net.

Book Review: Don't make me think

Kartones — Sun, 15 Jan 2012 22:07:00 GMT

New book review, I had this one pending so let's remove pending tasks :)

Don't make me think is about website usability, but really well written so that non-UX people like me can read it fast and easy. Go read the review first, then the full book!

Book Review: Don't make me think was posted the 01/15/2012 at Kartones.Net.

Building a Wordpress 3 Mobilizer plugin

Kartones — Wed, 04 Jan 2012 20:30:07 GMT

Here comes another chapter in my fights against Wordpress plugins' lack of quality code :)

For the small blog I have to toy with WP and try to optimize it, one of the tasks I had in the TODO list was setting up a mobile version. A while ago I did a quick search and found a few mobile plugins, both for administration ( which I'm not interested in) and for visitors browsing (let's call them 'mobile themes' although they require quite some coding).

I had three candidates, so this last nights I decided to test them, with terrible results: Some directly not work (or at least not render the homepage posts list), others were so ugly regarding source code, that once again I went the 'do it yourself' path (which usually is also the fun one).

My requisites:

Do not reinvent the wheel: I don't want to code any complex Javascript, nor reimplement Wordpress and/or JQuery functions.
Basic mobile site: Home/post list, individual posts, and as much as mobile placeholders for other "unsupported" pages (for example supporting rendering search results but not providing a mobile search page).
Being able to toggle normal site back: Simple user story: I want to browse the normal version using my iPad, but not using my Phone. And I want to be able to choose.
No UI from scratch: I am both bad and lazy when it comes to CSS.
Support at least most grade A mobile devices: If it works in an old BlackBerry, nice, but I want iOS, Android, Windows Phone, Kindle and other current devices supported with HTML5 and Javascript.

JQuery mobile 1.0 has just been released, so It solved me two of the hardest requisites: It comes with nice themes (including a dark one!), it supports actual mobile devices, and I don't have to write almost any javascript for request handling (it intercepts and handles requests nicely).

I am not going to dig into how it works, because the documentation and samples are soo easy to follow. I built the whole mobile part in like two-three hours (counting some CSS overrides to better fit my desires).

I had a few other framework alternatives but this one was blazing fast to implement and as I was already using JQuery due to Wordpress, the impact was small (but I must say that 80KB for a mobile FW is a lot!).

As for how to plug a mobile theme into WordPress without rewriting much code, I went for the typical approach: Creating a plugin that switches the theme to the mobile one if detects a mobile device.

If you manage to do this, is the best approach, as you will reuse huge parts of your code and just provide another UI (and typically another client-side logic layer), but is not always possible.

Luckily, I could do it in wordpress with just some research.

This are the hooks/actions/filters/whatever you have to capture to either let return the function parameter (normal/desktop) or override with the mobile one:

add_filter('stylesheet', array(&$this, 'GetStylesheetFolder'));
add_filter('theme_root', array(&$this, 'GetThemeRootPath'));
add_filter('theme_root_uri', array(&$this, 'GetThemeRootUri'));
add_filter('template', array(&$this, 'GetTemplatesFolder'));
add_action('wp_footer', array(&$this, 'AddFooterSwitcher'));

Credit from learning which ones to use goes to WPTouch plugin developers who found it.

The fifth hook is for my requisite of "Being able to toggle normal site back". I inject in the theme footer a small hyperlink and javascript o set a cookie to allow me to override the mobile theme if desired:

public function AddFooterSwitcher()

{
    if ($this->mode == Mobilizer::MODE_MOBILE)
    {
        echo '<a href="http://www.xxxxx.com',
            $_SERVER['REQUEST_URI'],
            '" onclick="Switch()" data-ajax="false">Switch to Desktop</a>',
            $this->GetCookieModeSwitchJavascript();
    }
    else
    {
        echo '<a href="http://www.xxxxx.com',
            $_SERVER['REQUEST_URI'],
            '" onclick="Switch()">Switch to Mobile</a>',
            $this->GetCookieModeSwitchJavascript();
    }
}

And this is the switcher code:

public function GetCookieModeSwitchJavascript()

{
    return
        '<script type="text/javascript">function Switch() {' .
        'var expiration = new Date();expiration.setDate(expiration.getDate() + 365);' .
        'document.cookie = "' . self::$cookieName . '=' .
        ($this->mode == Mobilizer::MODE_NORMAL ? Mobilizer::MODE_MOBILE : Mobilizer::MODE_NORMAL) .
        '; expires="+expiration.toUTCString()+"; path=/";' .
        '}</script>';
}

The logic to decide the mode is very simple:

If detected as mobile device*:

Override cookie present and set to normal mode -> leave normal
Override cookie not present or set to anything except normal mode ->set mobile

else -> leave normal

* I have also a dev IP override (a variable) to do local tests

Mobile detection is fairly simple using a simple regexp , I didn't wanted anything complex:

public function IsMobile()
{
if (self::$devIpOverride != null && strcmp($_SERVER['REMOTE_ADDR'], self::$devIpOverride) === 0)
{
    return true;
}
if (isset($_SERVER['HTTP_X_WAP_PROFILE']) || isset($_SERVER['HTTP_PROFILE']))
{
    return true;
}
if (strpos($_SERVER['HTTP_ACCEPT'], 'text/vnd.wap.wml') > 0 || strpos($_SERVER['HTTP_ACCEPT'], 'application/vnd.wap.xhtml+xml') > 0)
{
    return true;
}
return (bool) preg_match("/(iphone|ipod|ipad|android|blackberry|kindle|iemobile|ppc|smartphone|windows phone|psp|symbian|smartphone|opera mini)/i",
        strtolower($_SERVER['HTTP_USER_AGENT']));
}

To hook the plugin early enough so that no theme initialization code has been performed, I added this hook:

add_filter('plugins_loaded', 'MobilizerInit');

Code for the mobile pages is very simple HTML5 with the data-xxx attributes of JQuery mobile, for example this is the single post template:

<?php load_template(TEMPLATEPATH . '/header.php', false); ?>
<div data-role="page" data-theme="a">
    <div data-role="header">
        <a href="http://www.darkmillenniumcodex.com" data-icon="home" data-iconpos="notext">Index</a>
        <h1>Dark Millennium Codex</h1>
    </div>
    <div data-role="content">
    <?php if (have_posts()) : while (have_posts()) : the_post(); ?>
            <h4><?php the_title(); ?></h4>
            <p>
                <strong>Date:</strong> <?php the_time('m.d.Y') ?>
            </p>
            <p>
                <strong>Categories:</strong> <?php the_category(', ') ?>
            </p>
            <?php the_content(); ?>
            <?php comments_template(); ?>
    <?php endwhile; ?>
    <?php endif; ?>
    </div>
    <div data-role="footer">
        <?php load_template(TEMPLATEPATH . '/footer.php', false); ?>
    </div>
</div>
</body>
</html>

Some PHP fragments are really ugly, I know, but I haven't had time to properly clean the theme, I just grabbed a normal one, stripped out all CSS and markup and rebuilt a minimal mobile version. Wordpress is just so ugly by default.

And really there is not much else… One huge win with this approach is that all requests keep the same URLs, as we are only modifying the theme path and not the JS/PHP engines. The footer switcher function reloads exactly the same page you were visiting in the oppositve mode.

If you want to see it in action, just point a mobile phone, ipad or similar to http://www.darkmillenniumcodex.com and play with it (remember, in the footer you can always change the mode).

The full source code of the plugin and my theme is available here. Just read the notes and comments, should be easy to follow and setup.

Building a Wordpress 3 Mobilizer plugin was posted the 01/04/2012 at Kartones.Net.

Book Review: The Art of Readable Code

Kartones — Mon, 26 Dec 2011 19:43:30 GMT

It's been a while since my last book review, but lately I was reading non technical ones. I'm again reading a lot of tech stuff so here comes the last review of the year but first of a bunch I would like to post in the following weeks: The Art of Readable Code

Book Review: The Art of Readable Code was posted the 12/26/2011 at Kartones.Net.