374679 - Input box shouldn't be in the tab order

Status: RESOLVED FIXED

(Other Applications :: ChatZilla, defect)

Description

[:Gijs (he/him)]

To remedy the problem with the <Tab> key being used for both field navigation and tabcompletion, I've discussed for a bit with the accessibility people, and I think it would be best to make the editfield just not be part of the taborder. You can still focus it by using Esc or using F6 to switch between the content field and the input box, which seems good enough to me. This won't really disrupt normal users, nor will it be a problem for people dependent on keyboard navigation because they have an easy alternative.

James, Samuel, Rob, if you have comments please leave them here? :-)
I'll go and make a patch sometime this week.

Comment 1

[Aaron Leventhal]

Maybe there's no key conflict because autocomplete only needs to happen if there's text already typed.

So it can be in the tab order, and tab/shift+tab should work as long as the field is empty.

It seems more discoverable. When tab doesn't work as people expect they give up -- don't expect them to read any docs :(

Comment 2

[:Gijs (he/him)]

On an empty inputbox, <tab> will autocomplete to the last nick that messaged you or messaged a channel you're in while including your nickname. So that proposal is not really a possibility :(

It'd also be inconsistent.

Comment 3

[Aaron Leventhal]

Yeah but we're choosing between kinds of inconsistencies.

I guess that the empty field autocompletion to last chat-partner feature is new? I don't think it's discoverable enough. I wouldn't have guessed what it's doing even if I did try to type tab in an empty field and got someone.

Comment 4

[James Ross]

The <tab>-on-empty feature has existed since before time itself (at least since 2001-12-03 on trunk). Discoverability of the feature is not relevant to this bug - it stays.

Comment 5

[Aaron Leventhal]

James, I respectfully disagree and think it's relevant. I've been using Chatzilla forever as a keyboard user, and I never knew about that feature. Tab completion makes sense when you're in the middle of typing, otherwise tabbing should move in the tab cycle. People don't understand your UI. F6 to move focus is not going to be known and either is the empty autocomplete as reply feature.

My suggestion is that you have a _R_eply button if you want that, and let tab have two meanings depending on what makes sense at that moment.

Comment 6

[Samuel Sieb]

I agree with James.  I use <tab>-on-empty all the time.  I'm don't see what the point of being able to tab out of the input box would be.  The only other place that keyboard input is really useful is in the chat view.  Or is it possible to do something with the keyboard in the user list?  I don't see anything.

Comment 7

[David Bolter [:davidb] (NeedInfo me for attention)]

Tab based widget navigation is a very precious thing.

It must be really handy to use TAB for nick prediction. CTRL+Space is becoming common for completion/prediction (for example code completion in Eclipse). Would CTRL+Space be a decent compromise?

Comment 8

[James Ross]

Changing the completion shortcut is not a realistic option IMHO; TAB is so heavily ingrained on users - even those who don't use IRC much. F6 has been the standard switch-focus-area shortcut for as long as I cna remember in Firefox and Mozilla, and if it's not working well enough in ChatZilla that's a separate bug that should be fixed.

Removing the input from the tab order, as proposed in this bug, will allow tab to operate normally once outside the input box (cycling the userlist, chat area and tabs). F6 should cycle the chat area, input box and (I think) the userlist.

Comment 9

[:Gijs (he/him)]

We could at least make shift-tab tab back out of the input box (it currently doesn't). This will also allow people to use the nickname button more easily.

Charles Chen (author of the FireVox screenreader extension) suggested having a pref to turn tab-completion off, in which case "normal" tab-through-controls would "just work". It would then also be possible to automatically disable that pref from screenreader extensions like FireVox, so that people dependent on using screenreaders get a better first-hand experience. I'd also like to test what JAWS and WindowEyes do in mIRC (which they attempt to support), but I don't have a windows machine handy at the moment :(.

Whatever the case, I think we should at least fix shift-tab to go back in the tab order. As far as I can tell, we could pick from there to either:

- remove the input box from the tab order entirely (except for shift-tab to still get you out of there - people won't read docs on F6, I bet)

- add a pref to turn tabcompletion off to get the "default" formfield behaviour (perhaps replacing tabcompletion with ctrl+space as david suggested, if the 'normal' tabcompletion is switched off through that pref?)

Comment 10

[James Ross]

I'm not sure that making shift-tab hop out of the input box and then tab not going back into it is going to be so good, but without shift-tab hopping out I know people wont discover the way out. I'd much rather try to educate the users to F6 than prevent us from using shift-tab for reverse completion at a later stage.

Need to think about this some more...

Comment 11

[James Ross]

Gijs and I discussed this yesterday on IRC, and found we had both come to the same conclusions:

 - The input box should not in the tab order. You should not be able to tab to it
   or from it. This is for consistency.
 - Somewhere in the tab order, there needs to be the information that Esc will
   put you back in the input box. A suggested place would be the title for the
   nickname button, currently not set.
 - Somewhere there needs to be the information that F6 will cycle items,
   including out of the input box. A suggested place was the tab-completion list,
   when matching the empty string (i.e. instead of showing all the items).

Comment 12

[:Gijs (he/him)]

Attachment: Patch

Patch to:
- add tooltiptext to the nick button
- add F6 comment to the repeated-tab-without-anything-to-complete thing.
- force F6 to actually *work* (insert R-rated language here, cursing XBL, focus handling, xpcnativewrappers and everything else that got in my way that I forgot about by now)
- focus the input box on start, as it should have been since the beginning of time (yay for usability fixes)
- take both the input boxes out of the tab order.

Comment 13

[James Ross]

Comment on attachment 259961 [details] [diff] [review]
Patch

>+function advanceKeyboardFocus(amount)
>+{
>+    var contentWin = getContentWindow(client.currentObject.frame);
>+    var contentDoc = getContentDocument(client.currentObject.frame);
>+    var userList = document.getElementById("user-list");

Nit: blank line here.

>+    // Focus outputwindow, userlist and inputbox in turn:
>+    var focusableElems = [userList, client.input.inputField, contentWin];

Nit: Each time you list these 3 items, the order is different. Make sure the array and all comments match.

>+    

Nit: Whitespace.

>+    // Find my focus:

Nit: This and // Move the focus: are not particularily constructive comments, please remove them.

>+    var elem = document.commandDispatcher.focusedElement;
>+    // Finding focus in the content window is "hard". It's going to be null
>+    // if the window itself is focused, and "some element" inside of it if the
>+    // user starts tabbing through.
>+    if (!elem || (elem.ownerDocument == contentDoc))
>+        elem = contentWin;
>+    

Nit: Whitespace.

>+    var newIndex = (arrayIndexOf(focusableElems, elem) * 1 + 3 + amount) % 3;
>+    // Move the focus:
>+    focusableElems[newIndex].focus();
>+}


>+msg.leave.inputbox = There is nothing to tab-complete. Use F6 to cycle through the user list, chat output and the input box.

Nit: This list should also match the array and other comments.

r=silver with those nits fixed.

Comment 14

[:Gijs (he/him)]

Checking in mozilla/extensions/irc/xul/content/chatzilla.xul;
/cvsroot/mozilla/extensions/irc/xul/content/chatzilla.xul,v  <--  chatzilla.xul
new revision: 1.68; previous revision: 1.67
done
Checking in mozilla/extensions/irc/xul/content/handlers.js;
/cvsroot/mozilla/extensions/irc/xul/content/handlers.js,v  <--  handlers.js
new revision: 1.150; previous revision: 1.149
done
Checking in mozilla/extensions/irc/xul/content/static.js;
/cvsroot/mozilla/extensions/irc/xul/content/static.js,v  <--  static.js
new revision: 1.238; previous revision: 1.237
done
Checking in mozilla/extensions/irc/xul/locale/en-US/chatzilla.dtd;
/cvsroot/mozilla/extensions/irc/xul/locale/en-US/chatzilla.dtd,v  <--  chatzilla.dtd
new revision: 1.14; previous revision: 1.13
done
Checking in mozilla/extensions/irc/xul/locale/en-US/chatzilla.properties;
/cvsroot/mozilla/extensions/irc/xul/locale/en-US/chatzilla.properties,v  <--  chatzilla.properties
new revision: 1.133; previous revision: 1.132
done