An accessibility-related change in Gecko has a severe impact on the editor. If you test the editor with Firefox 2 (for instance using the Midas demo), pressing the Tab key when the caret is inside a list item indent the item to form a sublist. This is a behaviour common to most wysiwyg processors, office-like apps and wysiwyg web editors. We've been implementing it for ages, probably since Netscape Gold... Now try Firefox 3, and see it fail.

But because the Tab key is also use to move the focus in an application, people needing the Tab key for accessibility reasons get stuck into the editor if it acquires the focus... The editor consumes the key event and the focus remains where it is.

So the behaviour was changed and it's now totally impossible to indent/outdent a list using the tab key, but it's also totally impossible to insert a tabulation (\t) inside the editor (w/o hacking the new behaviour through JS) !!! And that is clearly unacceptable.

Accessibility. Accessibility... In my mind - but I could be wrong - solving accessibility issues should help people needing accessibility and improve their user experience, not harm the rest of the world and lower their user experience. I hope this is going to be fixed URGENTLY and a minor release of Firefox will bring back the original Tab behaviour in the editor to the masses AS SOON AS POSSIBLE.

Update : let's suppose your app is based on the editor. If you want your user to be able to insert a \t when he/she presses on the tab key,edito you'll have to override the new "normal" behaviour ANYWAY. Killing accessibility ANYWAY because your editor is going to consume the Tab key event ANYWAY. So what's the point of this change ?!?!?

Update 2 : I have mailed Chris Wilson (msft), Håkon Lie (opera), Dave Hyatt (webkit) and Peter, Aaron and MarcoZ (all Moz) about this issue to see if we can find a cross-browser solution preserving tab AND accessibility