Bug 19731 - should support focusin event
Summary: should support focusin event
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore JavaScript (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Nobody
URL: http://www.despair.com
Depends on:
Reported: 2008-06-23 14:13 PDT by Ojan Vafai
Modified: 2010-05-07 16:32 PDT (History)
3 users (show)

See Also:

shows focusin firing before focus (380 bytes, text/html)
2008-06-23 14:13 PDT, Ojan Vafai
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ojan Vafai 2008-06-23 14:13:02 PDT
The country dropdown in the checkout form on this site is broken. Each time you blur, then focus on the dropdown, the selected item is reset to the first item. The problem is that webkit is getting sent down the IE codepath because it supports event.srcElement, but doesn't have the focusin event.

The code does something like:
function onFocusIn(e) {
  if (e.srcElement) {
    e.srcElement.tmpIndex = e.srcElement.selectedIndex;

function onFocus(e) {
  if (e.srcElement) {
    e.srcElement.selectedIndex = e.srcElement.tmpIndex;

It's supposed to workaround some IE bug. In either case, webkit only hits the second codepath, which resets the selectedIndex to the first item (since tmpIndex is undefined). FF avoids both codepaths by not supporting srcElement.

Test case for the focusin problem coming. According to http://msdn.microsoft.com/en-us/library/ms536935(VS.85).aspx, it looks like focusin fires when the document's activeElement gets focus and it fires *before* the focus event.
Comment 1 Ojan Vafai 2008-06-23 14:13:42 PDT
Created attachment 21890 [details]
shows focusin firing before focus
Comment 2 James Robinson 2010-05-05 18:36:51 PDT
I think this is fixed, I always see focus before focusin on this test page.
Comment 3 James Robinson 2010-05-07 14:24:59 PDT
I misunderstood what this bug was about.  The spec says that focus should fire first, then focusin (http://www.w3.org/TR/DOM-Level-3-Events/#event-type-focusin), which is what we do.  It seems this page depends on the events firing in the other order.
Comment 4 Alexey Proskuryakov 2010-05-07 14:37:29 PDT
So, the part where we don't implement focusin is fixed, but the order is not what was mentioned in bug description. Is there a bug left here?
Comment 5 Ojan Vafai 2010-05-07 16:20:50 PDT
At the time I filed this bug, WebKit did not support focusin and the DOM events spec didn't mention it at all. We now support focusin. The order we fire it doesn't match IE and does match the spec. The site has changed, so there's no way to reproduce the original problem outside of the test case. Had the site still had the old code, it would still be failing because of the ordering problem.

I imagine this was because the spec compromised between DOMFocusIn as previously specced and focusin as exists in IE.
Comment 6 James Robinson 2010-05-07 16:26:52 PDT
OK, sounds like we should close this bug and then if the ordering turns out to be a web compat issue open a new one with a topical example.  Does that sound good to everyone?
Comment 7 Ojan Vafai 2010-05-07 16:32:07 PDT
I'm OK with that, especially since reversing the order might itself cause regressions due to focusin replacing DOMFocusIn, which we've supported for a long time.