Web Browser UI differences: refresh / cancel buttons

A few weeks ago I wrote about the differences in the 4 major browsers' search / address bar.  As promised, this is part 2 and highlights the subtle and not so subtle differences in how Firefox, Chrome, Safari and Internet Explorer handle the refresh and cancel actions.

IE 8  

Refresh and cancel are on the right of the address

Next to each other as separate buttons
Always available to press (no "go" button)

Firefox 3.6

Refresh and cancel are on the right of the address
Next to each other as separate buttons

Always available to press (no "go" button)

Firefox 3.6 loading

Spinner in the tab, now refresh and cancel are both available

Chrome 5

Single refresh button on the left of the address
A "go" button exists

Chrome 5 loading

Spinner in tab, now the "go" is a cancel button

I do not use the "go" button ever, instead rely more on the reload and back/forward buttons, therefore I find it inconvenient that the "cancel" is so far away and out of place compared to those buttons.

Safari 5

Single refresh button inside the address bar, small target region
No "go" button or cancel

Safari 5 loading

Spinner and text in address bar, entire region is a cancel button. 
Cancel in same place as the refresh, easy to click now as opposed to the initial refresh button

Summary

 Chrome's layout is too spread out and the least user-friendly in these regards.  Safari gets the loading part right (clear indication of loading, nice call to action to cancel and try again).   Overall, Safari is the only one to optimize for the "cancel and retry" action, which I find myself doing a lot when a site is struggling to load due to Internet connectivity issues or DNS hiccups.. however the initial refresh button is a bit small.

MLB up close

A recent trip to Dodgers stadium.  We got decent seats at field level, but the best views by far were in the 9th inning when we stood in the walkway behind home page.  Broxton came in to save the game after the Rockies threatened to tie it late.

It's the little things: Part 2

A few weeks ago I wrote about how Apple had made a subtle change to the reception bar graphics on the latest iPhone software update.  Today I discovered something in Snow Leopard's finder app that is even more subtle.

In Finder, the icons next to the Shared devices are detailed down to the black bevel around the screen! I just upgraded from a 2008 MacBook Pro that was all silver, to a shiny new aluminum MacBook Pro with the black screen.  With both devices connected, the icons were slightly different when viewing from my wife's computer.  (Note: OS X 10.5 does not support this, so yet another reason to upgrade to Snow Leopard...)

Given how many bugs and missing features plague finder (why can't you cut and paste a file?), it's a little depressing to think how much time may have gone into making these little icons work correctly.  Apparently the Bonjour protocol is rich enough to pass detailed information not only about the type of device that is being shared (computer), but also the kind of computer (laptop), as well as the line (macbook pro) and even the generation of macbook pro (aluminum unibody with black bevel around screen).

Mozilla Firefox exception when doing ajax call

If you have ever got the following exception in Firefox
uncaught exception: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIXMLHttpRequest.status]" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: http://localhost:3000/ajax2.html :: anonymous :: line 21" data: no]

or if you get this in Chrome:
Uncaught Error: INVALID_STATE_ERR: DOM Exception 11


Then you might be running into a bug where accessing "status" on the complete handler when the ajax request timed out causes a browser exception.  It is easy to reproduce using jQuery 1.3.2 (and 1.4.2) if you simply alert the xhr status after a timeout error.

Javascript code:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js" type="text/javascript">
</script>

<script type="text/javascript">
  jQuery.ajax( {
     url: "/sessions/new",
     timeout: 1,
     complete: function( xhr ) { alert( xhr.status ); }
  } );
</script>

I could not find a jQuery ticket or any bug reports. If you know of one, please post it in the comments!

The workaround is to simply check the text status provided by jQuery before trying to access xhr.status (and perhaps this is the only supported way to safely check the ajax status):

complete: function( xhr, text_status )
{
  if ( text_status == 'timeout' )
  {
    alert( 'TIMED OUT' );
  }
  else
  {
    alert( xhr.status );
  }
}

Browser quirks: invalid CSS color syntax

I had a typo in CSS, which led me to discover that the following css works in Chrome but not Firefox:

.my_text {
  color: #white;
}
<span class="my_text">Should be white text?</span>

Obviously the valid CSS would be either color: white or color: #ffffff but Chrome allows a mixture which may be dangerous if you are developing in Chrome and don't realize you have an invalid CSS style.

Note: Using Chrome 5.0 for Mac and Firefox 3.6 for Mac.