Make multiline mode more discoverable

NEW
Assigned to

Status

--
enhancement
11 years ago
4 years ago

People

(Reporter: SmoothPorcupine, Assigned: rginda)

Tracking

({access})

Trunk
access

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [cz-0.9.83])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

11 years ago
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

11 years ago
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
(Reporter)

Comment 2

11 years ago
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

Updated

11 years ago
Version: unspecified → Trunk

Comment 3

11 years ago
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

Comment 4

11 years ago
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

11 years ago
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

11 years ago
(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

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

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

Comment 8

11 years ago
Created attachment 323367 [details] [diff] [review]
[checked in] Make multiline go away on paste

There we are. :-)

(tested, works)
Assignee: rginda → gijskruitbosch+bugs
Status: NEW → ASSIGNED

Comment 9

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

Comment 10

11 years ago
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 11

11 years ago
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+

Comment 12

11 years ago
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]

Updated

11 years ago
Attachment #323367 - Attachment description: Make multiline go away on paste → [checked in] Make multiline go away on paste
Attachment #323367 - Attachment is obsolete: true

Comment 13

10 years ago
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

10 years ago
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

10 years ago
Created attachment 343545 [details]
Example of overlayed text

This is what I meant to do, honest.

Comment 16

10 years ago
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

Comment 17

10 years ago
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

10 years ago
(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?

Updated

8 years ago
Duplicate of this bug: 609534

Comment 21

8 years ago
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

4 years ago
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.