Native developer tools in Firefox

We are working on building a great set of developer tools for you included in Firefox. They are described much more in detail in Developer Tools in Firefox Aurora 10 and there are some very interesting implications for what we can accomplish with them!

We are evaluating and experimenting with a number of user interfaces and code approaches to try and find the most optimal ways to work with code in a page. If you install Firefox Aurora you can try them out right now! Let us know what you think.

Also stay tuned to this blog, since we will post updates on progress and features for the native Developer Tools.

Firebug

By far, the most well-known web developer tool in a web browser is the Firebug extension, and without a doubt, for a long time it set the bar for how web developing and debugging should be. Firebug is still a very important tool with lots of powerful features, including a vast number of extensions (see below).

Just something you need to be aware of, though, is with everything that Firebug offers it can be quite heavy when it comes to consuming memory, so use it accordingly.

Firefox extensions for web developers

Over the years, a lot of extensions have been developed to help web developers utilize Firefox to the maximum. Some of the most used and well-known are these ones, but please let us know if we have missed any that helps you!

Firebug extensions

There exists a lot of extensions for Firebug for a number of different use cases, and a number of them are listed here:

There are even more extensions available for Firebug, available in the Firebug Extensions wiki.

Since the first alpha version of Tilt was announced (a Firefox extension focused on creating a 3D visualization of a webpage), a lot of work has been done to add a great number of developer-oriented features. These focus on debugging the structure of a webpage, inspecting styling and attributes for each node and seamlessly refreshing the visualization when the DOM structure changes or after contents of document are repainted.

Solve nesting problems

Tilt is useful when searching problems in the HTML structure (like finding unclosed DIV elements for example) by providing the extra third dimension, layering each node based on nesting in the DOM tree. Stacks of elements visually represent branches in the DOM, and each node can be inspected for the inner HTML contents, its computed CSS style and the attributes.

Clicking anywhere on the visualization highlights a color-coded rectangle surrounding the corresponding node. Double click shows up the source preview for that node. Tilt also tries to show the most relevant information when needed (one is most likely to inspect the attributes of an input, button or image element, for example, but can easily switch between HTML, CSS and attributes view at any time).

Minidom map

The “minidom” is a tree view representation showing a minimalistic snapshot of the document object model. Each node is assigned a color associated by tag name (blue for div, green for span etc.) and represented as a strip, along with visual markers for the id and/or class if available. Each one of these strips also has a width relative to the type, id and class name length for the respective element, and the corresponding 3D stack in the visualization has color-coded margins. The coloring for individual elements is easily changeable using the color picker near to the minidom legend.

Clicking a strip in the tree view (or directly a stack on the 3D document visualization mesh) also highlights the node with a colored quad. This behavior is a good way to relate with the Style Inspector, and a more unified interaction between Tilt and other Developer Tools is planned in the future. All of these additions make it easier to analyze the bounds of each node, along with the HTML, computed CSS and attributes.

Realtime editing

Because Tilt is able to detect when a webpage’s DOM structure changes or when a repaint is necessary, integration is seamless with existing Developer Tools. Using Tilt and Firebug or Style Editor at the same time is easy. One can enable or disable CSS properties, changing the style of a node, and the visualization changes accordingly.

To enable realtime updates for the 3D webpage, go to the Options menu and check “Refresh visualization”.

Useful for learning

Developer tools such as “view source” have always been used to help people learn about web development. The 3D view highlights the structure of a page better than a flat view, thus anyone can immediately understand the parent-child relationship between nodes in a webpage, their positioning and how the layout is influenced.

One use case for this is the Hackasaurus mashup. The X-Ray Goggles is a nice and fun tool designed to make it easier to learn about the different document node types, the “building blocks” which create a webpage.

Export

A requested feature was the ability to export the visualization as a 3D mesh, to be used in games or other 3D editors. Tilt adds the ability to export to .obj, along with a material .mtl file and a .png texture (a screenshot of the entire webpage). The open .obj format ensures the fact that the mesh can be opened with almost any editor. Here’s a ray-traced rendering of hacks.mozilla.org in Blender:

Fun with experiments

As soon as it was released, many people found clever and interesting alternative ways to interact with Tilt. One experiment was creating a 3D visualization of an image, by exporting chunks of pixels to a HTML representation. The result was a voxel-like representation, with node blocks and stacks instead of pixels. A simple Image2Tilt converter was written in JavaScript, and you can try it directly in the browser.

Accelerometer support was another addition based on community request. This shows how easy it is to add functionality that wasn’t originally planned.

You can view the source code, fork it and also contribute to the addon with ideas or feature requests on Github, at github.com/victorporof/Tilt.

Available as an addon

The latest version of Tilt can be found on Github, but you can also download Tilt as an addon from addons.mozilla.org.

For compatibility, Tilt requires WebGL capabilities. Go to get.webgl.org to check availability and troubleshoot any issues. The current version works with Firefox 6.0 to latest 10.0 Nightly releases (latest Nightly builds now also support WebGL anti-aliasing, working great with Tilt).

To start Tilt, hit Control+Shift+M (or Command+Shift+M if you’re on Mac OS), or go to Web Developer -> Tilt, available in the Firefox application menu (or the Tools menu on Mac OS). You can modify this hotkey (and other properties) from the Options menu after starting Tilt.

More information about Tilt, the development process and milestone updates can be found on blog.mozilla.com/tilt.

Future

Tilt has become an active Developer Tools project, and an ongoing effort is made to integrate it with other existing tools like Style Inspector and Style Editor (source code and latest builds). As the 3D view of a webpage has proven to be useful for debugging, this main functionality will gradually become part of Firefox in future releases.

The good thing about this mess is that it taught us over the last few years to be paranoid in our development approach – we realised that in order to deliver working, accessible, maintainable and scalable systems we have to be professional and intelligent in our decisions and especially in our planning and architecting.

The trouble is that with the excitement around the cool new HTML5 things to play with a lot of these principles get lost and discarded as outdated. They aren’t – part of the mess that the web is in is that in 1999 a lot of people discarded everything else and instead worked only on the new hotness that was Internet Explorer 6 and DHTML. Let’s not repeat that mistake.

The two faces of HTML5 enthusiasm

Right now there are two things to get really excited about in HTML5: the richer, more meaningful semantics of new elements and the APIs that give us deep access into the workings of the browser and the operating system. The former allows us to build much richer interfaces and the latter allows us to build much more complex applications.

All of this comes with the awesome of view source (or check in development tools) for debugging. You can advocate HTML5 by writing clean and useful markup. You can kill it by treating the markup as a second class citizen which is only there to serve the script.

The markup enthusiasts are very happy about HTML5 and make it easy for people to upgrade – lots of cool new blog templates and boilerplate HTML templates are being built and polyfills created to allow using the new features and not leave behind outdated browsers.

On the app development side of things it looks much different and that is just sad. My only possible explanation is that people who come from desktop environments now tackle the HTML5 APIs without ever having to care about markup. The pragmatism of HTML5 allows a much more forgiving syntax than XHTML but it shouldn’t mean that we can just re-apply all the bad mistakes that held us back when it comes to maintenance for years.

During my career as a web developer I realised a few things make a lot of sense when building web apps:

• If there is an element for a certain task – use that one. It is very likely that the element comes with accessibility and interaction features for free that you would otherwise have to simulate.
• Separate CSS, JavaScript and HTML – which means it is easy to refactor your code without having to change all of them. It also means you can work in parallel with others instead of breaking each other’s code
• Never rely on markup or content – as sooner or later some editing tool will come into place that messes with everything you created

This means a lot of things:

• For starters it means that inline styles are simply evil as they override any settings you have in your style sheets. Only use them when this is exactly what you need to do or when you calculate them dynamically.
• The same applies to inline scripting. If you have an onclick="foo()" somewhere in your HTML and foo() changes to bar() you have to rename it in every HTML document (of course nowadays it is one template, but it still means hunting down a reference you might miss)
• If instead of using a native HTML element for a certain job you use SPANs and DIVs you’ll have to add classes to make them look and work – and simulate the keyboard accessibility, too.
• You can’t rely on the text value of any element. A <button>edit</button> using the “edit” as the trigger for certain functionality would have to have the JS localised, too when you create the German <button>bearbeiten</button>.

Bla bla bla… C’mon Chris, it isn’t that bad!

The above best practices have been mentioned for years and a lot of people get sick of seeing them repeated. After all, this is intelligent development and standard practice in backend technologies. I came across a lot of “creative” uses lately though when doing a view-source on HTML5 demos – specifically the ones in the HTML5 advent calendar. And here is my yield of what people do.

Simulating a navigation list

One of the first things I encountered was a painting tool that had a gallery of created graphics as a background. Now, to me this would be a simple list:

<ul>
  <li>
    <a href="{link}">
      <img src="{src}" alt="{title}">
    </a>
  </li>
  [...]
</ul>

The markup I found though was this:

<div id="sky">
  <div class="skyTile" style="{calculated styles};display:block">
    <img class="skyThumb" src="{src}" style="{generated styles}">
    <img src="images/thumb_dropShadow.png" 
         class="skyThumbShadow" 
         style="{generated styles}">
  </div>
  [...]
</div>

This, of course is generated by the backend. My first gripe is the dropshadow image, after all this is an HTML5 showcase – just use CSS3. We also have the three instances of generated styles and double classes. Granted, an extra class gives you a handle to all images instead of tiles, so why not. But as there is no real link around the image, the click handler has to read the url from somewhere. There is a lot of unnecessary back and forth between DOM and scripting here which does slow down the whole demo. Seeing that this is also the main navigation from the entry page to the editor this could be a list inside a nav element. A list groups these items together, a bunch of DIVs doesn’t (screen readers for example tell you how many items there are in a list).

Another list I found was supposed to be links to refresh the app and have a hierarchy but instead was a flat list with classes to define hierarchy and group:

<ul id="mitems">
  <li class="hedtop">Simple</li>
  <li class="mol">{name}</li>
  [... repeated ...]
  <li class="hed">{parent name}</li>
  <li class="mol">{name}</li>
  [... repeated ...]
</ul>

This could be OK, granted you also shift keyboard focus, but why not:

<nav>
<ul id="mitems">
  <li>{parent name}
    <ul>
      <li><a href="{url}">{name}</a></li>
      [... repeated ...]
    </ul>
  </li>
  [... repeated ...]
</ul>
</nav>

This would give you styling hooks and functionality for free. Links and buttons are great to trigger functionality – but it seems that is too easy.

Click (probably) here for functionality

If I build a button for an application to trigger a certain functionality this is the markup:

<button type="button" class="edit">Edit</button>

Buttons are what trigger functionality – both a backend script or a JavaScript. They are keyboard accessible, have a disabled state and sensible out-of-the-box styling that nowadays can be completely overwritten. The class can be the definition of what the button should do – instead of the text which will change. You could use an ID but a class allows to repeat buttons (for example on the top and the bottom of a results list).

The buttons I found though were slightly different:

<div id="homeButtonPanel">
  <div class="homeButton" id="drawHomeButton" 
       style="display: block;">
    <p>Start Drawing</p>
  </div>
  <div class="homeButton" id="viewHomeButton" 
       style="display: block;">
    <p>View the Mural</p>
  </div>
</div>
 
<div id="controlPanel" style="display: block;">
<div class="titleButton"><p>{title}</p></div>
  <div class="mainMenu">
    <div class="mainButton mainSelected" id="drawButton">
      <p>Draw</p>
      <div id="inkDisplay">
        <div id="inkMeter" style="width: 94px;">
        </div>
      </div>
    </div>
    <div class="menuContainer">
      <div class="menuButton drawMenuButton" id="behaviorsButton"
           style="display: block; opacity: 1;">
        <p>Gesture<br>Behaviors</p>
      </div>
    </div>
    <div class="menuContainer">
      <div class="menuButton drawMenuButton" id="artworkButton" 
           style="display: block; opacity: 1;">
        <p>Artwork</p>
      </div>
    </div>
    <div class="menuContainer">
      <div class="menuButton drawMenuButton" id="resetButton" 
           style="display: block; opacity: 1;">
        <p>Reset</p>
      </div>
    </div>
    <div class="menuContainer">
      <div class="menuButton drawMenuButton" id="undoButton" 
           style="display: block; opacity: 1;">
        <p>Undo</p>
      </div>
    </div>
    <div class="menuContainer">
      <div class="menuButton drawMenuButton" id="saveButton" 
           style="display: block; opacity: 1;">
        <p>Save</p>
      </div>
    </div>
  </div>
  <div class="mainMenu">
    <div class="mainButton" id="viewButton"><p>View</p></div>
  </div>
  <div class="mainMenu">
    <div class="secondaryButton" id="helpButton"><p>Help</p></div>
  </div>
  <div class="mainMenu">
    <div class="mainShare shareButtonSmall" id="mainTwitterButton">
      <img alt="twitter" src="images/twitter_icon.png" 
           style="opacity: 0.6;">
    </div>
    <div class="mainShare shareButtonLarge" id="mainFacebookButton">
      <img alt="facebook" src="images/facebook_icon.png">
    </div>
    <div class="mainShare shareButtonSmall" id="mainEmailButton">
      <img alt="email" src="images/email_icon.png" style="opacity: 0.6;">
    </div>
  </div>
</div>

So instead of using a nested list with classes for each button and the hierarchy in the nesting we have a lot of classes and a hand-rolled DIV construct. Instead of making buttons really disabled we rely on opacity and there is quite a mix of inline images and background images (if all were background images, they could be one sprite!). Keyboard navigation will have to be written for this and if you were to add a button you’d have to come up with another ID.

HTML5 actually has a construct for this. There is a menu element with command child elements. These are in use in Chrome’s side bar for example and should be what we use. If you want to make it work for everyone, a nested list with button elements is what to go for.

The overly complex DIV construct is quite used though – this was another example:

<div class="uiScreen" id="startScreen">
  <div class="panelBackground" id="mainResumeButton" style="display: none;">
    <div class="largeUIButton" id="resumeButton">Resume Game</div>
  </div>
  <div class="panelBackground" id="mainStartButton">
    <div class="largeUIButton" id="startButton">Start Game</div>
  </div>		
  <div class="panelBackground" id="mainHelpButton">
    <div class="largeUIButton" id="helpButton">Help</div>
  </div>
  <div class="panelBackground" id="mainHighscoreButton">
    <div class="largeUIButton" id="highscoreButton">High Scores</div>
  </div>
</div>

When in doubt – add an ID and class to everything.

Other buttons I encountered were actually links pointing to javascript:// using an inline style to indicate hierarchy:

<ul class="navlist">
  <li><a id="play" href="javascript://" 
         style="display: inline;">Play</a></li>    
  <li><a id="pause" href="javascript://">Pause</a></li>
  <li style="padding-left: 2px;">Effects:</li>
  <li><a id="bw" href="javascript://">Bw</a></li>
  <li><a id="outline" href="javascript://">Outline</a></li>
  <li><a id="color" href="javascript://">Color</a></li>
  <li><a id="invert" href="javascript://">Invert</a></li>
  <li><a id="matrix" href="javascript://">Matrix</a></li>
  <li><a id="old" href="javascript://">Old</a></li>
</ul>

Talking of inline – here’s a great example of a tool generating a lot of code that could be replaced by a single event handler and event delegation:

<div id="tools">
  <span onmouseout="buttonOut(1)" onmouseover="buttonOver(1)"
        onclick="buttonClicked(1)" id="button1" class="button">
    <img alt="" src="image/button/1.png">
  </span>
  <span onmouseout="buttonOut(2)" onmouseover="buttonOver(2)"
        onclick="buttonClicked(2)" id="button2" class="button">
        <img alt="" src="image/button/2.png">
  </span>
 
  [...repeated 20 times...]
 
<div id="toolsSeparator">&nbsp;</div>
  <a title="" id="toolbarButtonSave" class="toolbarButton"
     href="javascript:saveCanvas()">
    <img alt="" src="image/save.png">
  </a>
  <a title="New" id="toolbarButtonNew" class="toolbarButton"
     href="javascript:newCanvas()">
    <img alt="New" src="image/new.png"></a>
  <!--[if !IE]><![IGNORE[--><!--[IGNORE[]]-->
  <a id="toolbarButtonMenu" class="toolbarButton"
     onmouseout="closeMenuDelay()" onmouseover="showMenuHover()"
     href="javascript:showMenu()">
    <img alt="&gt;" src="image/menu.png">
  </a>
  <div onmouseout="closeMenuDelay()" onmouseover="overMenu()" id="menu">
    <a class="saveMenu" onmouseout="closeMenuDelay()" 
       onmouseover="overMenu()" href="javascript:saveCanvas()">
      save normal
    </a>
    <a class="saveMenu" onmouseout="closeMenuDelay()" 
       onmouseover="overMenu()" href="javascript:saveCanvasHi()">
      save high quality
      <span class="footnote">&nbsp; (rename to *.png)</span>
    </a>
    <a onmouseout="closeMenuDelay()" onmouseover="overMenu()"
       href="javascript:showAbout()">
      about...
    </a>
    <a class="lastMenu" target="_top" onmouseout="closeMenuDelay()"
       onmouseover="overMenu()" 
       href="{url}">
      <span class="footnote">
        <em>elsewhere:&nbsp;</em>
      </span>
      <em>a sound memory game</em>
    </a>
  </div>
  <!--<![endif]-->
</div>

Notice that if the images for the button couldn’t be loaded for one reason or another (or you can’t see them at all) this application is very confusing indeed – no alternative text for the images and no text content to fall back to. I am also very much sure that the in and out handlers trigger visual effects CSS could handle better.

Reasons and effects

I know there are probably good reasons for all of this, and I am sure I will also do things wrongly when I am rushed or want to get things out quickly. What we have to understand though is that right now we have a responsibility to show the best of breed demos we can.

We cannot preach the open web and technologies and view-source over closed systems and at the same time forget the things we learnt in the last decade. Some of these things I found look like code Frontpage or Dreamweaver could have produced in the 90ies and resulted in a lot of badly performing, hard to maintain products that either still annoy people who have to use them or get replaced every 2 years.

We have a mandate to educate the new developers coming to the web. Unlearning something is much harder than learning it – so let’s not start with bloat and quick fixes that work but forget to advocate clean code and thinking about the impact your product has on the end users (thinking accessibility) and the poor sods that will have to maintain your product when you are gone. We are not here to advocate effects and products, we are here to promote the tools that allow anyone to easily build something cool that is also easy to understand.

HTML5 is about evolving the web as a platform – we also need to evolve with it and take more responsibility. We have app and we have markup enthusiasts. Let’s make them work together to build things that are great functionality and clean semantics.

In addition, Thomas Robinson has created a very handy bookmarklet for debugging painting on a page you’ve loaded in the browser.

Due to popular demand, we’ve created a very experimental API for Firefox 3.5 to fire an event every time content is repainted. The event is is called MozAfterPaint and is fired at the document, bubbling up to the window. The event offers two attributes, clientRects and boundingClientRect, which tell you what was repainted, using the same objects and coordinate system as the getClientRects and getBoundingClientRect methods.

This is very useful for Firefox extensions and other “chrome” code that might be using the canvas.drawWindow method to capture the contents of windows. It might also be useful for tools like Firebug. But it’s also potentially useful for regular content, for example if you want to add some lightweight JS instrumentation to a page to measure what gets painted by Firefox, and when.

Caveats:

• This is Gecko-only. Do not use this for actual functionality on public Web pages – although I’m not sure why anyone would, so I don’t currently see this as a candidate for standardization.
• For security reasons, regular Web content is only notified of repainting that occurred in its own document – repainting caused by IFRAMEs is not reported to untrusted listeners attached to the IFRAME’s ancestors. (Listeners added by “trusted” content such as Firefox chrome are notified of all repaints to the window, however.)
• Currently the event might fire before the actual repainting happens. This shouldn’t matter much, and we’ll fix that at some point.
• If your event handler does anything that triggers repainting, such as changing the style of an element, you will probably trigger an infinite loop. The browser should stay responsive but your machine will contribute to global warming.
• Repainting of areas scrolled outside the viewport is reported, but repainting of areas scrolled outside overflow:auto elements and the like is not reported.
• Repainting in windowed plugins (i.e. most plugins in Windows and GTK) is not reported.