reply box loses focus after sending

Description

After sending a reply with <Ctrl>-<Enter>, the reply box loses focus.

Steps to Reproduce

Type a reply.
Press <Ctrl>-<Enter> to send.

Expected Behavior

The reply box regains focus (i.e., for a subsequent reply).

Actual Behavior

The reply box loses focus.

Comments

The chat UX idiom encourages people to (think they can) send multiple short messages in rapid succession, which is clumsy if the reply box can be submitted with the keyboard but must regain focus via the mouse.

It looks like this may be intentional(ish) behaviour, or behaviour we haven't standardized on:

securedrop-client/client/securedrop_client/gui/widgets.py

Lines 3166 to 3167 in d94eca3

    
           # Text area refocus flag. 
        
           self.refocus_after_sync = False

Originally I think this was introduced to avoid the replybox losing focus if a user was using the replybox while a background sync was applied. But a side-effect is the behaviour you mention (the replybox requires mouseclick or inconvenient tab/keyboard navigation in order to be refocused).

I think it's a fair point - it's inconvenient to get back to the replybox without using the cursor. I would say we should keep this open but not treat it as a release blocker - it's not a regression but we should put more time into all of our accessibility/navigation behaviours and making them consistent/predictable. That work for you @cfm ?

Oh, I absolutely agree that this is a long-standing UX inconsistency, neither a regression nor (remotely) a release blocker.