Thursday, February 7, 2008

Unsolved "Windows - No Disk" error with ipod nano

I have an ipod problem that's been plaguing me for months, and the all-knowing Internet has failed to provide an answer! I won't repeat all the details, because they are already well documented at

This also reminds me that Apple is goofy about not providing detailed release notes for software and firmware updates. Why do they do that?

Saturday, February 2, 2008

Javascript alert / confirm trap

Yesterday I hit a web page that contained an infinite javascript loop. That's usually not too bad, because the browser will recognize that and say something like, "A script on this page is taking too long -- stop it?"

The problem this time was that this javascript infinite loop had calls to both the alert and confirm functions. Those functions pop up modal dialog boxes. So instead of a loop that was chewing up cpu time, this one was popping up OK and Yes/No dialog boxes as fast as one could close them. The nasty bit is that these are both modal dialog boxes, so one cannot do anything else in the browser while they are displayed.

In the old days, I would have just killed the browser and restarted it. But these days, with tabbed browsing, I wasn't just killing that page, but all my other tabs, too. Fortunately for me, at the time I had no unsaved state in any tabs. If I did I would have lost it. There's no way to even copy/paste before killing the browser, because of the modal state.

Why can't a modern browser detect this situation and offer a clean escape? For example, if a page has popped up five modal dialogs within five seconds, then offer the user something like, "This page is opening dialog boxes quickly -- stop loading?"

Sample page demonstrating this trap:

<title>Modal Hell</title>
<script language="JavaScript">
function infinite_loop(txt) {
while (1) {

Can your browser break out of this?
<a name="foo"
onclick="infinite_loop('Now stuck')">
<u>Click me to start an infinite
modal dialog loop</u></a>