Bug 4814 – input does not receive onblur when switching to another window or application

• Component: DOM
• Status: RESOLVED DUPLICATE

[Patrick Geiller]

A focused input will not receive onblur when switching to another application. The input does visually 
blur, the event is not fired.

[Patrick Geiller]

Created attachment 3725 [details]
Test case for missing onblur

[Mark Rowe (bdash)]

Confirmed with WebKit 412.7 and ToT.

[Alexey Proskuryakov]

I don't see the expected behavior with Mac Firefox 1.5.0.1 (but it does call onblur when switching to another window, unlike Safari).

[Patrick Geiller]

> I don't see the expected behavior with Mac Firefox 1.5.0.1 (but it does call

I meant Firefox windows. Yes, Firefox Mac doesn't send onblur.  (But Firefox linux does ... Go figure !)

[Rob Buis]

Created attachment 8573 [details]
First attempt

[Rob Buis]

Created attachment 8574 [details]
First attempt

This implements a visual blur. It is possible the widget also needs to be set in
read-only mode. Also some layout tests now show up differently, I'll need to check
using winie to see whether that is right.
Cheers,

Rob.

[Adele Peterson]

Comment on attachment 8574 [details]
First attempt

Hmm.  This doesn't seem quite right to me.

I don't think the visual blur will match the Cocoa text field behavior.  Other than losing the focus ring, I don't see any change in text color or any other change in appearance when a text field blurs. If this is something that is done on other platforms then maybe we should move that logic to the RenderTheme.

I also don't think this solves the problem of the onblur event not firing when the window loses focus.  I think that probably needs to be fixed when the WebView resignsFirstResponder (although I'm not sure exactly when we should catch this)

[Rob Buis]

Hi Adele,

(In reply to comment #7)
> (From update of attachment 8574 [details] [edit])
> Hmm.  This doesn't seem quite right to me.
> 
> I don't think the visual blur will match the Cocoa text field behavior.  Other
> than losing the focus ring, I don't see any change in text color or any other
> change in appearance when a text field blurs. If this is something that is done
> on other platforms then maybe we should move that logic to the RenderTheme.
> 
> I also don't think this solves the problem of the onblur event not firing when
> the window loses focus.  I think that probably needs to be fixed when the
> WebView resignsFirstResponder (although I'm not sure exactly when we should
> catch this)

So as discussed on IRC, I misinterpreted this bug and started solving the wrong problem :}
Just to be clear, I am not too familiar with WebView and friends so I am leaving this to
someone else for now (not that it was assigned to me before).
Cheers,

Rob.

[Dave Hyatt]

It is currently intentional behavior that onblur not fire, although it could be worth discussing the behavior .

On OS X the element has not really lost focus.  Each window has a concept of a first responder (you can think of it as the focused element within the window) and then a separate concept of whether or not that window is active.  The element remains first responder for the window even when it is not active (and will regain its visual focused look when the window becomes active again).

This behavior is actually a really nice simplification, so if there's no significant compatibility reason to do this, I'd prefer to just close this bug as WONTFIX.

[Dave Hyatt]

For us, :focus in CSS means "am i focused and is the window also active."  It does not simply mean "am i focused", since that is true for us even when the window is not active.  This will work on other platforms like Win32 as long as they implement the Frame active stuff correctly (Win32 currently does not).

[Patrick Geiller]

I use onblur to hide the selection list of a custom combo box. Internet Explorer's onblur fires when the application becomes inactive, hiding (if visible) the combo's selection list in the process. That's nice, but ultimately it's just cosmetic — so WONTFIX is not a problem.

[Alexey Proskuryakov]

This was fixed in WebKit  as shipping with Safari 5.

*** This bug has been marked as a duplicate of bug 27105 ***