Bug 45843
| Summary: | can not prevent tab keys from performing their default action | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Jason Proctor <jason> |
| Component: | New Bugs | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | Normal | CC: | ap |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | OS X 10.6 | ||
| URL: | http://redfish.net/tab_bug/tab_bug.html | ||
Jason Proctor
usually when i register a keyup handler using jQuery, i can prevent the browser taking its normal action by calling preventDefault() on the incoming event.
however this doesn't seem to work with the tab key. the code behind the enclosed URL registers a keyup handler and also focus and blur handlers for all input tags. with the focus in the page, pressing tab should cause the keyup handler to fire first, then the input field should get focus *only* if i *don't* call preventDefault() on the event.
however, in today's WebKit nightly (and FF, btw) the focus event handler fires first, then the keyup handler. IMHO, this isn't right.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Alexey Proskuryakov
> in today's WebKit nightly
Is this a change from shipping Safari/WebKit 5.0.2? I think that we've always performed the tab action from keydown, and this seems correct to me.
Jason Proctor
sorry, i didn't mean to suggest that the issue was new in the nightlies, just that it *is* in the nightly.
should the tab key be different from other keys? it's not a modifier key - nothing happens until you let go - so IMHO it should be possible to prevent the default action by registering for keyup.
i can probably apply a hack with a keydown handler, but IMHO again, i shouldn't have to.
Alexey Proskuryakov
I see focus change before I release the Tab key in Safari (and "normal" typing also happens from keypress, not keyup). Just try pressing Tab here in Bugzilla and not releasing it.
> I think that we've always performed the tab action from keydown
Actually, I'm not sure offhand if it's keydown or keypress (the latter sounds more likely), just that it's not keyup.
Jason Proctor
if i bind to "keypress" instead of "keyup", I don't even get called for tab key presses at all.
binding to keydown seems to do the right thing, but tracking at that level requires more work.
seems like some classes of key are different to others? i'm seeing similar behaviour with return keypresses.
Alexey Proskuryakov
Yes, there are default event handlers for each event, and their actions can be different for different keys.
Please file bugs for any cases where observable actions of default handlers are different from Internet Explorer - we chose to match it as closely as possible for keyboard event handling.