[webkit-reviews] review requested: [Bug 33962] 'blur' event fired while modal dialog box is up : [Attachment 47229] Does not fire focus/blur events while a modal dialog is up

[bugzilla-daemon at webkit.org]

James Robinson <jamesr at chromium.org> has asked	for review:
Bug 33962: 'blur' event fired while modal dialog box is up
https://bugs.webkit.org/show_bug.cgi?id=33962

Attachment 47229: Does not fire focus/blur events while a modal dialog is up
https://bugs.webkit.org/attachment.cgi?id=47229&action=review

------- Additional Comments from James Robinson <jamesr at chromium.org>
This patch suppresses firing all focus events while a modal dialog is up (using
Page::defersLoading() to detect this case).  This is consistent with Safari
4.0.4 behavior, although it is a change compared to ToT WebKit.  Here is a
summary of what other browsers do when an <input> has a mouseup handler that
opens a modal dialog (window.alert/window.confirm) and a blur handler that sets
a timer (window.setTimeout):

Firefox 3.5.7 executes the 'onblur' handler when the modal dialog appears.  The
timer is set, but it does not fire until the time has elapsed _and_ the dialog
is dismissed.  While the dialog is up, the input area does not appear to be
focused (there is no blinking carrot or focus ring on OS X).  When the dialog
is dismissed, the input area is focused and looks focused (blinking carrot,
focus ring on OS X).

IE8 executes the 'onblur' handler when the modal dialog appears.  The timer is
set, but it does not start 'counting' until the dialog is dismissed (so on this
test page it does not fire until 5 seconds after the dialog is dismissed). 
While the dialog is up, the input area doesn't visibly appear focused.

Safari 4.0.4 on Windows does not execute the 'onblur' handler at all.  The
input area does not appear visually focused while the modal dialog is up.  Once
the dialog is dismissed, the input area still does not look visually focused
and does not receive text input, but when the user clicks anywhere else on the
page the 'blur' event still fires at the <input>.  This seems really buggy.

Safari 4.0.4 on OS X does not execute the 'onblur' handler at all.  The input
area does not appear visually focused while the modal dialog is up.  Once the
dialog is dismissed, the input area does look visually focused and does receive
text input (unlike on Windows).

WebKit ToT executes the 'onblur' handler while the dialog is up and fires the
timer while the dialog is up.  It also crashes with an assertion failure in
debug mode if the dialog is dismissed while the timer is still pending.

I do not think that website authors typically expect their code to execute
while another piece of code is blocked on a modal dialog.  This patch brings
behavior back to roughly the Safari 4.0.4 behavior.

Alternatively, we could still fire focus/blur events while modal dialogs are up
but ensure that all timers created are created in the suspended state.	Then
they would be resumed by the PageGroupLoadDeferrer when the dialog is
dismissed.  This would be closer to the Firefox/IE8 behavior, which is still
pretty odd IMHO.