RESOLVED FIXED 23763
blur/focus events not fired on focused element when WebView loses/gains focus
https://bugs.webkit.org/show_bug.cgi?id=23763
Summary blur/focus events not fired on focused element when WebView loses/gains focus
Adam Roben (:aroben)
Reported 2009-02-05 09:37:17 PST
When a WebView loses focus (e.g., by the user bringing another application to the foreground), a blur event does not fire at the focused element, but should. Firefox and IE both fire blur events at the focused element in this case.
Attachments
testcase (879 bytes, text/html)
2009-02-05 09:42 PST, Adam Roben (:aroben)
no flags
Adam Roben (:aroben)
Comment 1 2009-02-05 09:42:32 PST
Also, when the WebView later gains focus, we should fire a focus event at the focused element.
Adam Roben (:aroben)
Comment 2 2009-02-05 09:42:51 PST
Created attachment 27352 [details] testcase
Ojan Vafai
Comment 3 2009-02-05 12:18:47 PST
*** Bug 18815 has been marked as a duplicate of this bug. ***
Ojan Vafai
Comment 4 2009-02-05 12:21:10 PST
Also, related is 16928. Fixing this bug with out fixing bug 16928 would cause switching tabs to move your cursor to the beginning of any rich-edit field that it's in.
Ahmad Saleem
Comment 5 2023-10-21 03:38:01 PDT
I am getting following in Safari Technology Preview 181: <input> blurred main frame blurred main frame focused <input> focused ^ which are expected ones. Do we have to do anything else? I get following from Chrome Canary 120: <input> blurred main frame blurred main frame focused <input> focused and Firefox Nightly 120. <input> blurred main frame blurred main frame focused <input> focused ___ All browsers are matching as mentioned. Do we need to do anything else? CCing - Abrar since he is working on event handling and Ryosuke for his input. I think we can mark this as 'RESOLVED CONFIGURATION CHANGED'.
Ryosuke Niwa
Comment 6 2023-10-23 15:35:02 PDT
This appears to have been fixed by now.
Note You need to log in before you can comment on or make changes to this bug.