client: re-focus input on chat form submit

[williamboman]

Closes #481

[astorije]

The whole focusing thing needs to be reworked, but I guess it will do for now. Have you tried how this change reacts on mobile?
👍 Retracted for now.

[maxpoulin64]

Hmm, I'm not a fan of the bahavior on mobile. For me, it causes a text selection to be created which is somewhat annoying:

It also forces the virtual keyboard to open, even if it was closed. I think this is pretty annoying. Keyboard can stay open if it was open, but reopening it is kinda bad.

I think I found a solution, opening a PR for it.

EDIT: Ok, it doesn't work on mobile. Anything that involves .focus() will trigger the virtual keyboard to pop open, and my workaround doesn't work because the field is always focused even if I close the keyboard. There's no solution for this.

I very much prefer the current behavior to an even buggier one, especially considering we already totally abuse focusing already. So that's a 👎 for me until we find a proper solution.

Things I tried:

• preventDefault in several handlers (click, blur, focusout). None will cancel the switching in any way.
• We do have a way to know the focus is switching to the button, but using focus here to "cancel" it still forces the keyboard to open on mobile. Eww.
• CSS pointer-events: useless in this case, and letting the tap go through will bring the damned keyboard again. Urghh.

Seems like the only solution to this problem would be to add a layer on top of the button and manually detect if we hit the "button" without letting the actual click go through. That in turns break the hover effect and is really ugly.

[astorije]

Great analysis, thanks @maxpoulin64!
I suggest we sleep on it, keep that open for now, and prioritize other issues/improvements with the message field. I'm also going to be paying more attention to other apps and websites working that way to see how they deal with it.
Adding the do not merge label so it can stay open without getting another review/merge.

[xPaw]

I'd prefer for this to land too, however the virtual keyboard is definitely not something we want to ship. Currently lounge avoids opening it by doing this:

        if (screen.width > 768) {
            input.focus();
        }

which is not ideal to say the least.

[astorije]

Per @maxpoulin64 and @xPaw's comments above, can we do s/input.focus();/focus();/ until there is a solution for the virtual keyboard, at the very least?
That would not solve all issues nor be a definitive solution, but the re-focusing on-click-on-send-button would work consistently with submitting by hitting Enter.

Thoughts?

[astorije]

@maxpoulin64, @xPaw, I just saw that @williamboman updated his PR accordingly. Are you ok with that now? I haven't tested yet btw.

[maxpoulin64]

I'll try to give this a quick try tomorrow as I don't really remember what was the issue and why it was so complicated.

[astorije]

@maxpoulin64, issue was mobile keyboard was being a bitch. Now this PR doesn't affect mobile anymore so let's !
Added 2.2.0 milestone because I'm pretty sure it became a no-brainer.

[xPaw]

I think I found a fix for opening the virtual keyboard (also removes the screen width test):

    function focus() {
        if (chat.find(".active").hasClass("chan")) {
            input
                .attr("readonly", true)
                .focus()
                .removeAttr("readonly");
        }
    }

[astorije]

Holy 🐮, what the hell is that!
@xPaw, where/how did you find this?
Since at first glance it looks like a hack, how confident are you this is going to work cross-browser or cross-mobile-OS?
This offers a different solution but based on the same idea. Still requires a shower afterwards though...

By the way, is the problem Android-only or does iOS have the same issue?

[astorije]

@xPaw, regardless of this attempt to make it work on mobile, can we merge that PR? It still is an issue on desktop :-/

[xPaw]

Thats a pretty common way of hacking something to do a specific thing without triggering something you c don't want to. I certainly want to merge a full fix (because on my phone the keyboard opens whenever I switch channels).

[astorije]

I certainly want to merge a full fix (because on my phone the keyboard opens whenever I switch channels).

Agreed this needs fixing, but the full fix you are referring to is not a direct comparison to what this PR is fixing: not re-focusing (on desktop only, for now) after clicking on the submit button.

My point is: What is preventing us to merge this PR, for the issue it's trying to solve, and apply your fix/find an optimal fix in a different PR, for that different issue we are having?
This PR is a one-liner and has been opened 3.5 months ago. I really think we can push the Merge button here!

[astorije]

I think I found a fix for opening the virtual keyboard (also removes the screen width test):

I wanted to open a PR with that fix but testing it is not very conclusive :(

• On desktop (Mac OS X, Chrome), it works fine, with one glitch: after focus() was called, the blinking prompt disappeared. If I type, everything works as if the focus is properly set, but right before typing, prompt has disappeared ¯_(ツ)_/¯
• On mobile (Nexus 4, Android 5), it does not work: focus gets given to the input, but the virtual keyboard gets closed, whether it was opened or closed before calling focus().

Ah, this is frustrating. I'm starting to think we're better off writing a function based on awful assumptions: if there is a sudden decrease/increase in height but not in width of the window, then keyboard was opened/closed...

---

EDIT: Even worse with .attr("disabled", true) / .removeAttr("disabled") as given in the SO thread above.

Basically, input.focus() forces the keyboard to open, input.attr("readonly", true).focus().removeAttr("readonly"); forces the keyboard to close, but there is nothing I can find that would let us click on anything without changing the state of the keyboard...

[xPaw]

@astorije could check if the input is already focused, unsure needs testing. Merging this anyway.