Catch tab keypress events and prevent default (Trac #1618)

[sleemanj]

Browsers behave inconsistently when the tab key is pressed in a contenteditable window. I think none of the browsers' behaviors are desired:

• Webkit inserts a <span class="apple-tab-span" style="white-space pre"> </span> at the current position, causing any subsequent text on the line to be advanced four spaces ahead. This might be desired behavior sometimes.
• Gecko lets the event reach the browser window itself; it therefore causes the Xinha editor frame to lose focus, which (depending on what's in the parent frame) might switch to a different editing context, or cause the user to inadvertently submit a form, or start typing in the browser's Location bar.
• I haven't checked what IE does.

When the cursor is within certain contexts (lists, tables) I think the tab key should be caught and some context-specific behavior should occur (#1614, #1617). But when no relevant context is found, I think Xinha should still catch the keypress event and prevent the default behavior.

Possibly there should be a framework here that:

• allows plugins to register an html context that can catch the tab event and do something different
• allows integrators to choose a default tab behavior

But those options are technically already available at a lower level using event subscribers, so a minimal patch that just catches and stops the event is probably sufficient.

Reported by ejucovy, migrated from http://trac.xinha.org/ticket/1618

[sleemanj]

ejucovy commented:

Related thread: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0047.html

[sleemanj]

• @sleemanj commented:

1378 Does this for both Gecko and WebKit. Configurable by tabSpanClass and tabSpanContents options, inserts (or removes for shift-tab) as the name suggests, spans. It works surprisingly well.

• @sleemanj changed resolution to fixed
• @sleemanj changed status from new to closed