Bug 4814 - input does not receive onblur when switching to another window or application
Summary: input does not receive onblur when switching to another window or application
Status: RESOLVED DUPLICATE of bug 27105
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML DOM (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Dave Hyatt
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-09-02 13:52 PDT by Patrick Geiller
Modified: 2010-06-11 15:01 PDT (History)
2 users (show)

See Also:


Attachments
Test case for missing onblur (693 bytes, text/html)
2005-09-02 13:55 PDT, Patrick Geiller
no flags Details
First attempt (2.85 KB, patch)
2006-05-27 14:34 PDT, Rob Buis
no flags Details | Formatted Diff | Diff
First attempt (2.85 KB, patch)
2006-05-27 14:35 PDT, Rob Buis
adele: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Geiller 2005-09-02 13:52:16 PDT
A focused input will not receive onblur when switching to another application. The input does visually 
blur, the event is not fired.
Comment 1 Patrick Geiller 2005-09-02 13:55:30 PDT
Created attachment 3725 [details]
Test case for missing onblur
Comment 2 Mark Rowe (bdash) 2005-09-03 01:50:04 PDT
Confirmed with WebKit 412.7 and ToT.
Comment 3 Alexey Proskuryakov 2006-02-08 12:07:56 PST
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).
Comment 4 Patrick Geiller 2006-02-09 12:10:36 PST
> 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 !)
Comment 5 Rob Buis 2006-05-27 14:34:01 PDT
Created attachment 8573 [details]
First attempt
Comment 6 Rob Buis 2006-05-27 14:35:38 PDT
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.
Comment 7 Adele Peterson 2006-05-30 00:07:17 PDT
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)
Comment 8 Rob Buis 2006-05-30 12:42:35 PDT
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.
Comment 9 Dave Hyatt 2006-09-12 23:43:32 PDT
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.
Comment 10 Dave Hyatt 2006-09-12 23:45:12 PDT
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).
Comment 11 Patrick Geiller 2006-09-13 10:10:23 PDT
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.
Comment 12 Alexey Proskuryakov 2010-06-11 15:01:40 PDT
This was fixed in WebKit  as shipping with Safari 5.

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