Apparently, there are only two hard problems in computer science: cache invalidation and the naming of things (or so Phil Karlton’s dictum goes). Earlier this month, we invited representatives of Twitter, Facebook, SproutCore, Palm’s webOS, Microsoft’s “Office On The Web”, Yahoo, and Google to talk to us about the former problem (amongst other things), though we also learned something about the latter.

Caching is an important issue to get right on the web, not least of all because of the proliferation of web applications on mobile devices. The goals of our caching summit were to identify use cases that would help us move forward with caching and with HTTP request efficiency. How desirable was rolling up our sleeves to look at HTTP/1.1 Pipelining in Firefox, for instance? What else was needed at the HTTP layer? And was the vaunted HTML5 AppCache, implemented in Firefox 3.5 onwards, actually useful to developers? What else needed to be exposed to web applications, either within content or via additional headers?

Developer feedback is invaluable, and is increasingly the basis of how we want to evolve the next integral pieces of the web platform. Web developers are one of our primary constituencies; going forward, we want them to help us prioritize what we should implement, and what we need to focus on with respect to web standards. We chose our attendees wisely; if any group of people could talk about web applications at scale, the current performance of the cache, and their wishlist for future browser caching behavior on the web platform, it was this group of people. And the feedback they gave us was copious and useful — our work is cut-out for us. Notably, we’ve got a few actions we’re going to follow-up on:

A cool new browser event just recently landed in the latest Firefox nightlies: an event announcing when the browser re-draws a portion of the page.

This particular event, called MozAfterPaint fires whenever something is drawn to the screen.

The event object contains two properties: .clientRects and .boundingClientRect, both of which refer to the result of the associated DOM methods.

In a nutshell, boundingClientRect gives you a single rectangle encompassing the entire area in which a paint operation could've taken place whereas clientRects gives you a number of rectangles, each encompassing an individual area that was drawn.

To test this I created a quick demo using CNN.com (only works in the latest Firefox nightlies).

John Resig posted today about a nifty new feature available in Firefox nightlies, browser paint events. He also posted an example script and bookmarklet called TrackPaint. He goes into greater depth in his post, so I won’t bother here.

I wanted something more “real-time” and closer to the Quartz Debug utility included with the Mac OS X developer tools (which essentially provides this feature for all of OS X), so I present my modified bookmarklet and code:

Nightly Tester Tools

This extension adds a few extras useful to those that regularly test nightly builds of Firefox, Thunderbird, Sunbird and Toolkit Seamonkey (Suiterunner).

Don’t forget that forcing an incompatible extension to install is risky. There are many cases where Firefox will stop working completely or behave incorrectly because an incompatible extension is being forced to work where the author never intended.

The following is a brief list of the extension’s features, for the full set of features please take a look at the features list.

* Extension compatibility fixing
* Titlebar customisation
* Build ID retrieval
* Screenshots
* Breakpad information
* Restoring tabs from previous session
* Leak log analysis

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.

Stats.js
Javascript Performance Monitor

Flattr this

This class provides a simple info box that will help you monitor your code performance.

* FPS Frames rendered in the last second. The higher the number the better.
* MS Milliseconds needed to render a frame. The lower the number the better.
* MEM Mbytes of memory allocated. Make sure it doesn't keep incrementing. (Webkit-based browsers only)

Screenshots

Since I’ve been playing around with user management a lot lately, I thought I’d share a simple technique I picked up. This technique will allow you to easily add new user profile fields that your blog’s users can use to input more information about themselves.

Management of these fields will be coming in a later version of my user management plugin, but some of you may want to do this now.

In this tutorial, I’ll show you how to add an input box for a Twitter username and how to display it on your site, which will look a little something like this: