Summary: | should support focusin event | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Ojan Vafai <ovafai> | ||||
Component: | WebCore JavaScript | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | jamesr, ojan, ovafai | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | PC | ||||||
OS: | OS X 10.5 | ||||||
URL: | http://www.despair.com | ||||||
Attachments: |
|
Description
Ojan Vafai
2008-06-23 14:13:02 PDT
Created attachment 21890 [details]
shows focusin firing before focus
I think this is fixed, I always see focus before focusin on this test page. 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. 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? 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. 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? 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. |