I was playing with the dialog overlay (modal) and noticed that in trying to prevent the user from interacting with the page under the overlay, it is also preventing the use of some basic browser functionality.  Basically the overlay captures a list of events (focus,mousedown,mouseup,keydown,keypress,click) and says that if the event did not happen in the current dialog then prevent the event.  This works fine for mouse events, but when it comes to keyboard events it is also preventing access to the actual browser interface as well.  For example, if you open a dialog with a modal and then try to use ctrl-r to reload or ctrl-p to print, nothing will happen.  The interesting thing is that if you happen to focus on, say a input (or something else focusable) in your dialog, and then try to use the ctrl-r to reload, it works, because technically in this case the event came from the dialog.  

Unless you are explicitly trying to prevent it, I think that by default you should never block the basic browser keyboard shortcuts.

One solution might be to remove keydown and keypress from the default overlay events, and let the focus move to a valid focusable element.  Another might be to just allow ctrl-<anything> to pass through.  Although you still might want to allow a user to TAB into the browser interface, i.e. the URL, if you could, especially for accessibility purposes.

My two cents.  What do others think?