Opened 6 years ago

Closed 2 years ago

#1618 closed enhancement (fixed)

Catch tab keypress events and prevent default

Reported by: ejucovy Owned by: gogo
Priority: normal Milestone:
Component: Xinha Core Version: trunk
Severity: normal Keywords:


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.

Change History (2)

comment:2 Changed 2 years ago by gogo

  • Resolution set to fixed
  • Status changed from new to closed

[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.

Note: See TracTickets for help on using tickets.