Open Bug 417196 Opened 12 years ago Updated 5 years ago

Make multiline mode more discoverable

Categories

(Other Applications :: ChatZilla, enhancement)

enhancement
Not set

Tracking

(Not tracked)

People

(Reporter: SmoothPorcupine, Assigned: rginda)

References

Details

(Keywords: access, Whiteboard: [cz-0.9.83])

Attachments

(1 file, 1 obsolete file)

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.
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).
Version: unspecified → Trunk
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] **/
...
Version: Trunk → unspecified
Version: unspecified → Trunk
Morphing per comment #1
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Tab completion does not work in multiline input mode → Make multiline mode more discoverable
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.
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.
(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.
Oh, doh. I just realized how this will fail. Sigh:

- paste
- collapse
- expand
- send --> autocollapse == huh?
There we are. :-)

(tested, works)
Assignee: rginda → gijskruitbosch+bugs
Status: NEW → ASSIGNED
(In reply to comment #7)
That would be why I included the 2nd point in the list. ;)
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.
Attachment #323367 - Flags: review?(silver)
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.
Attachment #323367 - Flags: review?(silver) → review+
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.
Whiteboard: [cz-0.9.83]
Attachment #323367 - Attachment description: Make multiline go away on paste → [checked in] Make multiline go away on paste
Attachment #323367 - Attachment is obsolete: true
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?
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
This is what I meant to do, honest.
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?
Keywords: access
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.
(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?
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?
Duplicate of this bug: 609534
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)
I'm not currently working on this.
Assignee: gijskruitbosch+bugs → rginda
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.