GRRRRRRR !!!
By glazou on Wednesday 6 August 2008, 10:30 - Mozilla - Permalink
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
Comments
Even though I understand your frustration, I've always been irked when tabbing through forms and suddenly not being able to continue because of hitting a text field. The FF 2 behavior in no way was better than what we have now in FF 3. Ideally we'd have a focus key and a tabbing key. As of FF 3 the tab key has gone to 100 % focus key: Tab for in page/window navigation, Ctrl+Tab for tabs and Alt+Tab in most environments for switching windows. So there's not even an easy and sensible key combination that I could come up with for inserting tabs (even Ctrl+T and Alt+T are used). Difficult thing to resolve intelligently.
Marco, Peter and Aaron can't really make the decision alone. Is there a Mozilla bug tracking your frustration (I seem to recall there being one, and me having similar frustrations within it)? Please loop me in on this email thread you started.
Netiquette generally discourages the use of all caps (http://en.wikipedia.org/wiki/All_ca...)
Option-Tab is a well-known standard method.
If you hope this to be fixed URGENTLY, then FIX IT!
The netiquette remark was spot on, by the way.
It just hit me that a solution like depressing the tab key for a few seconds would toggle between focus switching mode (the default) and the wysiwyg/text editing mode would be a fair compromise (problems remains like how to behave outside a text editor, it should be decided a priori or settable through configuration).
A status indicator in the status bar would then show which mode is active.
I don't know If this can be made as an extension (or embedded in your editor component ?), but should it be the case, you could solve your problem now.
Actually, I'm on Kubuntu with Firefox 2.0.0.16 and I can't make a tabulation on this comment. When I hit the Tab key, it change the focus. (but maybe I miss something since I'm not at all a developer)
I think this behavior is correct for accessibility. But when I've started to write something (other than a tabulation) the editor in my opinion, should switch to an other behavior an let me use the tab key to insert a tabulation. And an other key (like escape, maybe) should let me switch again on the "change focus" behavior of the tab key.
So when I do <tab><tab><tab>, I change focus 3 times even if one of the element is an editor.
And when I do <tab><tab>blablabla<tab>blabla<esc><tab>, I'm done to the same place, but I write "blablabla\tblabla" in the editor (the second element).
Hopes I didn't say something totally off topic.
Et si c'est incompréhensible, je peut peut-être le refaire en français... désolé pour mon anglais tout pourris
I see your frustration. The Firefox textarea input field doesn't allow tab insertion, but Thunderbird's compose window has always allowed tab insertion and tab-to-indent; I wonder if TB 3.0 alphas are different.
Ctrl-]/[ is the documented accelerator in the menu for Format > Increase/Decrease Indent in Thunderbird and Kompozer. As for tab insertion, my workaround for textareas is to select a tab character from another program and copy'n'paste it in to the textarea: That was one. That was another.
It's a hack, does it work for your problem?
"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"
Adding editor features should help people needing those features and improve their user experience, not harm the rest of the world and lower their user experience.
I believe more users navigate web pages using the Tab key than indent lists on the web using the Tab key. You should be able to find another key for that feature; Tab is taken.
"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 ?!?!?"
To fix keyboard navigation and accessibility on sites that use designmode but don't care about indented lists or tab characters. I believe that's the majority of sites that use designmode.
Also, who says the sites that re-add the feature using JavaScript have to use the Tab key to do it?
I can't see the problem with "hacking the new behaviour through JS". I do that all the time. But next time I will certainly remember the tip from comment #7: TAB consume begins when the user enters text in the editor, and gets released when ESC is pressed. Sounds like a fair compromise. This is already the default behavior to escape from an accidentally opened selectbox. If the editor was focused by use of the tab key, a text "press escape" could even be presented to introduce the concept.
for some layouts - IDE style layouts, where an editor can often be found - navigation by tab key is not very elegant anyway, at least not unless heavily modified by script. Consider an average Eclipse or Visual Studio workbench layout. In web technology, this would almost certainly be produced by multiple iframes. Navigating between these using the tab key is not easy, but also not expected by the user - whereas the tab key is certainly expected to work for indentation in text editors. The editor can imho not be designed to fit both scenarios; so a little JS hacking is fine with me.
I've always found the inability to easily enter a tab character into a textarea to be extremely frustrating. Personally I'm in favour of something like Chocolat's solution above:
* If I explicitly click into a textarea, or if I tab into one then start typing, assume I want to switch to "edit mode" where the TAB key indents or inserts a \t character
* Once in "edit mode", pressing ESC will switch back to "focus mode", allowing TAB to be used to navigate to the next control.
* In all other cases TAB acts as a focus control - so if I TAB into a textarea but don't type anything, the next TAB will take me straight out of it.
As this switching of modes is somewhat unintuitive, this would be disabled by default and enabled via a hidden pref (otherwise there'll be plenty of bugs filed when tab focus seems to stop working). When the focus is in a textarea then an indication of the operating mode in the status bar or via some other mechanism would be useful, though not essential.
MarkC: I like that solution best. (I already suggested a similar solution in the bug: https://bugzilla.mozilla.org/show_b...)
I also think it should be on by default, because I can't think of any accessibility reason against it. With the proper border-highlighting, it should be completely obvious what's going on.
I must admit that I'm getting a little frustrated that this obvious solution which is win-win for everyone keeps getting ignored.