Bug 19731 – should support focusin event

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore JavaScript

[Ojan Vafai]

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.

[Ojan Vafai]

Created attachment 21890 [details]
shows focusin firing before focus

[James Robinson]

I think this is fixed, I always see focus before focusin on this test page.

[James Robinson]

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.

[Alexey Proskuryakov]

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?

[Ojan Vafai]

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.

[James Robinson]

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?

[Ojan Vafai]

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.