Editor: [patch] [ccla] [regression] provide a mode to allow use of tab key within editor

[Becky Gibson]

#3812 implements tab/shift-tab key navigation into/out of the rich text editor to make it keyboard accessible

There are people who are concerned about this change since it eliminates the use of tab/shift-tab within the editor to indent/outent items. Would like to provide a mode to allow this behavior when the rich text editor is the only item on the page and thus keyboard navigation out of the editor may not necessary. Although I'm not sure there is ever a case when navigation out of the editor is not necessary - the user needs some mechanism to save or send the current editor contents. So, may need to provide a different keyboard mechanism for getting into /out of the editor or a different way to indent/outdent

[bill]

Hopefully Cougar can review this but I have a few comments.

First, presumably if a developer uses this plugin, it prevents a keyboard user from getting to the Toolbar, so the ticket description (about using this when there is nothing else on the page) seems disingenuous. Even in that case it will mess up keyboard users, so might be better to rephrase as "if you don't need full keyboard support in your app" (and to document that in the plugin).

As for technical issues, it seems like you shouldn't need the isTabIndent parameter to the Editor; shouldn't just including the plugin (in extraPlugins) be enough?

Also BTW there's a little weird indenting in the patch itself, probably used spaces instead of tabs.

[liucougar]

Replying to bill:

First, presumably if a developer uses this plugin, it prevents a keyboard user from getting to the Toolbar, so the ticket description (about using this when there is nothing else on the page) seems disingenuous.

One way around this is to provide a default shortcut key to toggle the action as well as a toolbar button

As for technical issues, it seems like you shouldn't need the isTabIndent parameter to the Editor; shouldn't just including the plugin (in extraPlugins) be enough?

there is currently no way of changing execCommand behavior in an editor plugin without hijack that function in Editor (which is dangerous if user has subclass of Editor). So I guess we have to leave that code in RichText/Editor?

[Becky Gibson]

udated to add ctrl+m key combo to invoke and move tab handling to editor.js

[Becky Gibson]

I added 4607a.patch to move the tab handling code into editor.js before the undo code. I also added ctrl+m as a key combination to enter and exit tab editing mode. I could just add this key combination when the tabIndent plugin is used but it seemed worthwhile to add in general.

[liucougar]

looks ok, we can fine tune it once it is committed

[Becky Gibson]

(In [14056]) refs #4607 added support for a mode to use the tab and shift-tab keys to indent outdent list items. Also added ctrl+m as keyboard shortcut for this behavior. Created a simple icon which needs additional work. Needs more work in FF2 on OSX

[Becky Gibson]

(In [14384]) refs #4607 updated editor.css and editor.gif for soria and nihilo. TabIndent? button could use a review from design folks.

[Becky Gibson]

this is tied to #7632 because you can't indent/outdent via the keyboard if indent itself is broken. But even after fixing #7632 tab indent is still broken because the focus no longer is retained after the indent/outdent command. The tab indent broke in the 8/7/2008 build.

[Becky Gibson]

see #7640 for patch

[Becky Gibson]

(In [15282]) fixes #4607 #7640 removed code that was setting selection in richtext focus/blur that was added during refactor and was causing focus problems in IE. Fixed onkeydown handlers in editor and richtext - there was duplicate tab handling code after the "backport" of the editor back to 1.1.1.

[bill]

(In [20443]) When user types Ctrl-M in the editor to toggle tab-indent mode, the tab-indent button's checked state is updated accordingly. Avoid that state change causing a button onChange() event, which triggers a call to the editor to set it's tabIndex.

The old code was harmless as it just reset the tabIndex to it's current value (a no-op), but it's better form to distinguish between user button-presses and programmatic changes.

Refs #4607 !strict