Larger area to click on to enter a message

[turt2live]

Description

Some people I work with have found it frustrating/annoying how small the message entry field is, leading them to click "a thousand times" before being able to type their message. The clickable area should probably be larger.

Steps to reproduce

• alt+tab to another window
• Furiously click the browser window to try and send a message
• Be enraged

Log: not sent

Version information

• Platform: web (in-browser)
• Browser: Chrome 60
• OS: Windows 10
• URL: riot.im/develop (and internal based on v0.12.2)

[t3chguy]

I agree, clicking anywhere below that horizontal line (and within the invisible side confines) should fire a focus_composer dispatch, (assuming it was not a click of one of the buttons)

[lukebarnard1]

This is fairly tractable. I would suggest an onClick for "mx_MessageComposer_input" that launches a dispatch with the necessary check to make sure it was indeed the input that was clicked on.

I'd also suggest changing the cursor to the text cursor /w CSS.

This would give focus for the yellow area shown here:

[turt2live]

I'd still like to see the entire bar clickable. I also find myself clicking random areas of the bar, hoping to get focus on the composer.

[lukebarnard1]

That would effectively be "mx_MessageComposer_row". I wouldn't mind putting that on develop and seeing how it feels.

[lampholder]

I think we've spoken about this IRL, but as a chat application, by far the most common thing people will be doing is typing into the composer.

We could just interpret any keypress that isn't otherwise handled as being intended for the composer and return focus there. This... sounds like something that could cause untold misery if we implement it quickly and naively, though.

[turt2live]

I'd very much like to be able to mash my keyboard and have a message automatically work. This issue was kinda intended to be a "stepping stone" to that issue though :)

[lukebarnard1]

We could just interpret any keypress that isn't otherwise handled as being intended for the composer and return focus there

untold misery

Yep. I'd rather define something(s) much smaller in scope for regaining focus on the composer. Things that should probably focus the composer:

• Clicking in the "composer"
• Focusing the window
• After swapping rooms (already done)

[t3chguy]

Focusing the window

this used to be the case and was removed by me because when clicking from another Window into Riot onto something like Filter room names or Filter room members you'd instead be sent to Composer

[turt2live]

The focus logic could be improved for that. If you focus onto something that is logically focusable, then focus on that, else onto the composer.

[lukebarnard1]

The focus logic could be improved for that. If you focus onto something that is logically focusable, then focus on that, else onto the composer.

Actually, when you focus on something, the element with focus will be remembered if the entire window loses focus.

So actually we should deliberately not focus the composer when the window is given focus.

This leaves

Clicking in the "composer"

We may have to investigate individual cases where the composer loses focus and we could look into other events that could preempt giving focus to the composer.

[t3chguy]

So for now I implemented something along the lines of

Leaving this issue open in case its insufficient/etc etc

[turt2live]

In practice I think this is done now