[Webkit-unassigned] [Bug 33962] 'blur' event fired while modal dialog box is up

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=33962





--- Comment #16 from Dmitry Titov <dimich at chromium.org>  2010-02-03 16:30:07 PST ---
After some looking around I think the ASSERT in timer code is a red herring
here. Firing events on a page that is already in a modal UI means more JS
reentrancy. Very few JS developers are prepared to handle reentrancy, that's a
good reason to 'freeze' the page behind the modal UI. It seems the good analogy
is Cocoa NSApplication's runModalForWindow - it stops all events (including
timers) on other windows.

One reason why innocently-looking JS can easily shoot itself in the foot in
presence of JS reentrancy is bug 18315 which pop ups alerts on top of each
other and prevents the page from being closed (in ToT). That bug will be fixed
with the proposed patch too.

If FF loads images and fires load events behind the modal UI, then they
probably have some code in place to deal with an HTTP Auth or "bad cert"
dialogs that may pop up while loading images, or perhaps there is some way to
'defer' another alert() that JS code in the event handler may want to pop up.
This can be done but it adds complexity and additional code and queues, etc.
For example, the network layer of the embedder may continue to pull the bits
off the network while events may be deferred (or blocked on the attempt to nest
another modal UI, which seems to require more support). This behavior likely
needs case-by-case consideration.

Since in modal UI case the focus remains on the same element after modal UI is
dismissed, I can see a reason not to fire focus events at all in this scenario
(no 'blur' and no 'focus'). As James noted, the risk of compat issue is 
mitigated by the fact that shipping Safari does not fire those.

It might be deemed necessary to prevent/defer other sources of events
(worker.onmessage for example) from being dispatched while modal UI is up, or
deal with effects of those in some other way, but it likely would require
separate patches anyways.

So I'm negating my previous remark, and think the patch is reasonable.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.