417196 - Make multiline mode more discoverable

Status: NEW

(Other Applications :: ChatZilla, enhancement)

Description

[SmoothPorcupine Pirate]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1.11) Gecko/20071128 SeaMonkey/1.1.7 Mnenhy/0.7.5.0
Build Identifier: 0.9.80

When using the multiline input box (ID "multiline-input") tab completion does not work. The problem is in handlers.js, in functions onMultilineInputKeyPress and onTabCompleteRequest.

Reproducible: Always

Steps to Reproduce:
1. Switch to multiline input mode.
2. Use tab completion as usual.
Actual Results:  
Tab completion did not happen.

Expected Results:  
Tab completed.

Comment 1

[James Ross]

It is actually by-design.

Although not mentioned that often, it does come up semi-regularly in #chatzilla that people "can't tab-complete" or "must use Control-Enter to send" which are both manifestations of being in the multiline mode.

I kinda think that some visible UI to highlight the non-normal mode would be a better use of our time than trying to make it act the same as the single-line box (which is tricky, what with conflicting shortcuts and such).

Comment 2

[SmoothPorcupine Pirate]

This code seems to fix the problem:
>function onMultilineInputKeyPress(e){
>  if ((e.ctrlKey || e.metaKey) && e.keyCode == 13){
>    /* meta-enter, execute buffer */
>    onMultilineSend(e);
>  }else{
>    if ((e.ctrlKey || e.metaKey) && e.keyCode == 40){
>      /* ctrl/meta-down, switch to single line mode */
>      dispatch ("pref multiline false");
>    }
>// [New Code]
>    else if (!e.ctrlKey && !e.metaKey && e.keyCode == 9){/* tab */
>      onTabCompleteRequest(e);
>      e.preventDefault();
>    }
>// [/New Code]
>  }
>}
...
>function onTabCompleteRequest(e){
>  var elem = document.commandDispatcher.focusedElement;
>// [New Code]
>  var singleInput = document.getBindingParent(elem);
>// [/New Code]
>/** [Removed Code] **\
>  var singleInput = document.getElementById("input");
>  if (document.getBindingParent(elem) != singleInput){return;}
>\** [/Removed Code] **/
...

Comment 3

[:Gijs (he/him)]

Morphing per comment #1

Comment 4

[:Gijs (he/him)]

As a first thing, I'd like to switch back to single-line input after sending a pasted multiline thing. This way, we don't open the thing for them, which will alleviate some of the problems, I believe.

Comment 5

[James Ross]

So perhaps something like:
 - When paste/DnD expands box, set flag.
 - User toggling expansion (either way) clears flag.
 - Sending text when flag is set will collapse box and clear flag.

Comment 6

[:Gijs (he/him)]

(In reply to comment #5)
> So perhaps something like:
>  - When paste/DnD expands box, set flag.

>  - User toggling expansion (either way) clears flag.
I don't think we need this specific point. I have a patch without this bit already, just tested it, seems to work. Am I missing a complicated sequence of collapsing/expanding/pasting that will throw the thing off without this code?

>  - Sending text when flag is set will collapse box and clear flag.
> 


Here's my list:
- on dnd paste expansion in a single line box, set flag
- on multiline send, check for flag. If set, collapse box and clear flag.

You can't switch to multiline when you've pasted something, because the paste code actually toggles the pref.

Comment 7

[:Gijs (he/him)]

Oh, doh. I just realized how this will fail. Sigh:

- paste
- collapse
- expand
- send --> autocollapse == huh?

Comment 8

[:Gijs (he/him)]

Attachment: [checked in] Make multiline go away on paste

There we are. :-)

(tested, works)

Comment 9

[James Ross]

(In reply to comment #7)
That would be why I included the 2nd point in the list. ;)

Comment 10

[:Gijs (he/him)]

Comment on attachment 323367 [details] [diff] [review]
[checked in] Make multiline go away on paste

Ugh. I would have sworn I asked for review on this one.

Comment 11

[James Ross]

Comment on attachment 323367 [details] [diff] [review]
[checked in] Make multiline go away on paste

>+    if (client.multiLineForPaste)
>+        client.prefs["multiline"] = false;

Nit: please check client.multiLineForPaste exists as well, since you neither initialise it nor leave it afterwards.

r=silver with the nit fixed.

Comment 12

[:Gijs (he/him)]

Checking in mozilla/extensions/irc/xul/content/handlers.js;
/cvsroot/mozilla/extensions/irc/xul/content/handlers.js,v  <--  handlers.js
new revision: 1.179; previous revision: 1.178
done
Checking in mozilla/extensions/irc/xul/content/prefs.js;
/cvsroot/mozilla/extensions/irc/xul/content/prefs.js,v  <--  prefs.js
new revision: 1.55; previous revision: 1.54
done

Leaving bug open for possible future work.

Comment 13

[:Gijs (he/him)]

Hrm, so what about indicators? How would we usefully indicate a multiline input? Seems like an interesting problem, and I don't really have a good solution. Any proposals?

Comment 14

[James Ross]

The kind of thing that'd look good is "Multiline Input Mode (Control-Down to end)" in large, mostly-transparent disabled-colour text right over the middle of the multiline input box. I'd expect the accessibility people would cry at that, though. ;)

E.g. http://galinstan/temp/cz_33.png

Comment 15

[James Ross]

Attachment: Example of overlayed text

This is what I meant to do, honest.

Comment 16

[:Gijs (he/him)]

Well... I'm not sure. I would hope/suspect that screenreaders and/or Mozilla tell the user that the type of input box changed, regardless of what other cues we implement.

I actually have trouble reading the text in this screenshot. Could we pick a darker shade so the contrast is a bit bigger?

Comment 17

[James Ross]

Well, I picked a random grey in my image editor and placed it on top at 50% transparency; if we did do this, I'd want to use the actual disabled text colour which is likely darker. However, the idea was that it was visible enough to be readable when the box is empty but not so that you can't see what you're typing.

As for accessibility, I was thinking of the readers actually reading the text (or more likely not) that'd be fun.

Comment 18

[:Gijs (he/him)]

(In reply to comment #17)
> Well, I picked a random grey in my image editor and placed it on top at 50%
> transparency; if we did do this, I'd want to use the actual disabled text
> colour which is likely darker. However, the idea was that it was visible enough
> to be readable when the box is empty but not so that you can't see what you're
> typing.
Fair enough.

 
> As for accessibility, I was thinking of the readers actually reading the text
> (or more likely not) that'd be fun.

I suppose. I have no idea if that's possible - I doubt it, but maybe Aaron and Marco could weigh in on this, and how you think we should tackle this? We wouldn't like to use a title attribute because for sighted users it gets in the way when used on a multiline textbox... Are there other options?

Comment 19

[Marco Zehe (:MarcoZ)]

Well, to pick up this discussion. What's happening is that there is a new accessible created. In braille, I immediately see the difference when I press Ctrl/Cmd+UpArrow to go to multiline. Also, speech behaves as if focus just changed to a different textbox control.
When this originally hit me, I had pasted something multiline into the single line control. It changed to the multiline, but then, the JAWS version I was using didn't interact that well yet to XUL applications. I just tried the same steps agin, and after pasting, JAWS 10 immediately tells me that something changed. Speech behaves as if focus changed, so I know something requires my attention.

What I'd suggest to do is put some form of description onto the control via aria-describedby. Does the visual indicator other than the colour have any text you cold reuse for that?

Comment 21

[Joc]

If the nickname completion is not fixed, at least the FAQ should indicate that the nickname completion works only in the single-line input mode (press the down arrow on the right side of the input window)

Comment 22

[:Gijs (he/him)]

I'm not currently working on this.