All users were logged out of Bugzilla on October 13th, 2018

Improve keyboard navigation

RESOLVED FIXED in 1.2

Status

RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: aleth, Assigned: aleth)

Tracking

(Blocks: 1 bug)

Dependency tree / graph

Details

(Whiteboard: [1.2-wanted])

Attachments

(1 attachment)

(Assignee)

Description

5 years ago
*** Original post on bio 1234 at 2012-01-14 18:22:00 UTC ***

This is to collect and discuss some thoughts on improving keyboard navigation in the conversation window.

Problems with the status quo:
- Shift-PgUp/PgDn and Alt-PgUp/PgDn are not discoverable at all
- It is unfortunate to have to remember use Shift-PgUp/PgDn when one wants to PgUp/PgDn in the browser. It is not intuitive.
- This is a symptom of the more general problem that the navigation keys one would expect as standard for the browser (Home, End, Ctrl-Home/End, PgUp/PgDn, Cursor Up/Dn) are also needed in the edit box, certainly as soon as multiple lines are entered. And the edit box usually has focus (as it should).
- Conversely, Shift-PgUp/PgDn and Alt-PgUp/PgDn (chosen in the first place to workaround this problem) currently do not work in the browser window (bug 954300 (bio 867), bug 954643 (bio 1211)).
- There is little room for further navigation shortcuts (as might be required e.g. for "scroll to previous/next search result" in the future) without them getting more and more complicated. (Note Ctrl-PgUp/PgDn are already taken for jump to next/previous tab.)

Due to the conflict between navigating the textbox and the browser no perfect solution seems possible.

Existing proposal: Mic's Easy Scrolling (https://addons.instantbird.org/en-US/instantbird/addon/290)
The idea here is to assume that when the text box is empty and the user tries to navigate, he intends to scroll the browser and not the textbox. Therefore {Home, End, PgUp/PgDn, Cursor Up/Dn} act on the browser in this case. Home/End and Ctrl-Home/End are (or should be) interpreted as section scroll. (In the future one could e.g. differentiate between Home/End and Ctrl-Home/End if further navigation keys are required.)

This behaviour is eminently discoverable and I would propose including it in IB by default. 


The principle would be that

1)  When the textbox is empty, it should not matter whether the browser or the textbox has focus.
 
2)  When it is not empty, standard navigation keys apply to whatever has focus.

3)  'Special' navigation keys should continue to be available _in addition_ so browser navigation is still possible while entering a message. These should always work indepently of what has focus (ie, Bug 954300 (bio 867) and 1211 should be fixed). They won't be very discoverable but they are there for frequent users.


A more radical suggestion would be to hide the edit box until the user starts typing. This would make the suggested behaviour completely intuitive. 

To avoid too much visual jumping around, once the edit box is shown, it would only be hidden again after some reasonably long timeout (so if you are actually in a conversation, it does not vanish just after you press Enter, only to pop up again a second later).

Any comments/thoughts?
*** Original post on bio 1234 at 2012-01-14 18:58:28 UTC ***

(In reply to comment #0)

> A more radical suggestion would be to hide the edit box until the user starts
> typing. This would make the suggested behaviour completely intuitive.

It would then become impossible to discover that you can actually type. I know  people who won't start typing until they have clicked in the textbox where they want their typed text to go (even when that textbox was already focused and the cursor was already blinking there).

> To avoid too much visual jumping around, once the edit box is shown, it would
> only be hidden again after some reasonably long timeout (so if you are actually
> in a conversation, it does not vanish just after you press Enter, only to pop
> up again a second later).
> 
> Any comments/thoughts?

That radical suggestion, even though it's not acceptable for the default behavior, could make an interesting add-on.
By the way, I think the textbox should already be visible in the case where there's no message yet in the conversation.
(Assignee)

Comment 2

5 years ago
*** Original post on bio 1234 at 2012-01-14 19:58:33 UTC ***

(In reply to comment #1)
> That radical suggestion, even though it's not acceptable for the default
> behavior, could make an interesting add-on.

I actually agree with that (hence the 'radical' ;). But what about the main part? Are there any other good alternative solutions?
*** Original post on bio 1234 at 2012-01-15 22:50:09 UTC ***

(In reply to comment #2)
> (In reply to comment #1)
> > That radical suggestion, even though it's not acceptable for the default
> > behavior, could make an interesting add-on.
> 
> I actually agree with that (hence the 'radical' ;). But what about the main
> part? Are there any other good alternative solutions?

Comment 0 is a bit long, but if the "main part" is "forward the arrow key events fired on the empty textbox to the browser", then I think it's something we should do.
(Assignee)

Updated

5 years ago
Depends on: 954300
(Assignee)

Updated

5 years ago
Depends on: 954643
(Assignee)

Comment 4

5 years ago
Created attachment 8352870 [details] [diff] [review]
Patch

*** Original post on bio 1234 as attmnt 1126 at 2012-01-22 12:44:00 UTC ***

This patch implements 1) - 3) from comment #0 and fixes bug 954300 (bio 867) and bug 954643 (bio 1211).

A set of navigation keys are passed to the browser when the textbox is empty. IB-specific navigation key combinations are always passed to the browser. Thus, all browser navigation key event handling can happen in convbrowser.xml.

New navigation key behaviour compared to the status quo: Home/End and Ctrl-Home/End in the browser now map to section scroll.
Attachment #8352870 - Flags: review?(florian)
(Assignee)

Updated

5 years ago
Assignee: nobody → aleth
Status: NEW → ASSIGNED
(Assignee)

Updated

5 years ago
Status: ASSIGNED → NEW
Whiteboard: [1.2-wanted]
*** Original post on bio 1234 at 2012-01-22 15:34:31 UTC ***

(In reply to comment #4)

> New navigation key behaviour compared to the status quo: Home/End and
> Ctrl-Home/End in the browser now map to section scroll.

What about letting Home/End jump between sections and Ctrl+Home/End to top or end of the conversation instead? That would be a bit like the behaviour of a lot of text editors, where Home/End work on the current line while Ctrl+Home/End jumps to the beginning or end of the document instead?
(Assignee)

Comment 6

5 years ago
*** Original post on bio 1234 at 2012-01-22 18:00:01 UTC ***

(In reply to comment #5)
> What about letting Home/End jump between sections and Ctrl+Home/End to top or
> end of the conversation instead? That would be a bit like the behaviour of a
> lot of text editors, where Home/End work on the current line while
> Ctrl+Home/End jumps to the beginning or end of the document instead?

I'd be happy with that as well. The reason I mapped them both to section scroll is that at one point there was a discussion on IRC that in the future, it might be nice to have "subsections" (e.g. for search results or pings) and then you'd want to have room in the key mapping for "jump to next/prev subsection". So in this case the current section scroll would in the future only remain with Ctrl-Home/End (since you have at most 3 jump destinations there, it's only a small addition to document beginning/end), while Home/End would become subsection scroll. Also, it's worth keeping in mind that if/when infinite scroll is implemented, there would be many more sections (e.g. on date changes or session/conversation starts) and the beginning of the document at least loses some of its importance.

But I may be misremembering the long-term plan here, and I don't think anything firm was decided upon. So comments would be good ;)
*** Original post on bio 1234 at 2012-01-23 22:13:50 UTC ***

Do we actually need all these key bindings that jump/scroll independently from text in the input box? Is the case of "scrolling, when there's something in the input box" important enough to use so many modifiers+keys for it? And then there's not even a pattern which modifier makes a key go to the browser instead of the input box.
*** Original post on bio 1234 at 2012-01-24 11:20:42 UTC ***

If the formatting of this posting here in Bugzilla hurts your eyes to much, you can also read it here: http://pastebin.instantbird.com/9818

---

I'm investigating different cases of focused elements and key events here. Behaviour is linewise scrolling for Up/Down, pagewise scrolling for PageUp/PageDown and section jumps for Home/End. I'm assuming that people would try these keys first (no modifiers!) because they're the most simple combination [1]. The following cases are labelled with WORKS/FAILS regarding scrolling of conversation content:


When the CONVERSATION BROWSER is FOCUSED:
  * Up/Down: WORKS
  * PageUp/PageDown: WORKS
  * Home, End: WORKS
  
When the INPUT BOX is FOCUSED
  W/O INPUT:
    * Up/Down: WORKS
    * PageUp/PageDown: WORKS
    * Home, End: WORKS


  W/ INPUT:
    * Up/Down: FAILS [2]
    -> problem if the user already entered something and wants to scroll the viewport only a few lines. Might only happens if the message is out of sight in reach of a few lines (and doesn't if someone uses PageUp/PageDown to scroll there)?
    * PageUp/PageDown: [3a]
    ** NO SCROLLBAR on the input box: WORKS, if we're willing to accept the non-standard behaviour with respect to the caret (see [3b])
    ** SCROLLBAR on the input box: FAILS (unlikely to happen since we have the auto-expanding input box that almost always prevents getting a scrollbar there?)
    * Home, End: FAILS [4]

[1] Additionally I think it's not worth to have a lot of key combinations (there's no simple modifier that would allow to always scroll the browser instead of the input box) which would only be needed in a few edge cases. If someone really needs to have them, he could always write and add-on to customize them? In the few cases where cases above fail, you can always tab to the browser or click it to get the focus there. I don't think it really hurts, especially since it would be clear why the keyboard shortcut *had to* fail (because the user's moving his caret(or viewport) around in the input box).
[2] We don't have an always working replacement for this.
[3a] We currently have Shift+PageUp/PageDown as always working replacement that would become more or less useless because it would only cover the unlikely case where we can't scroll using PageUp/PageDown.
[3b] Shift+PageUp/PageDown introduced non-standard behaviour with respect to selection already.
[4] Alt+PageUP/PageDown and Ctrl+Home/End (this one also breaks standard caret behaviour!) are replacements that always work. This is the only case where I think that it might be necessary to have a always working solution?
(Assignee)

Comment 9

5 years ago
*** Original post on bio 1234 at 2012-01-24 20:06:18 UTC ***

(In reply to comment #8)
Thanks for the long comment Mic! 

Comparing your ideas with the current patch, I see three changes your are potentially asking for:

1) Let PgUp/PgDn scroll the browser from the editbox even when text is entered, as long as no scrollbar is present.

2) Remove the existing Shift-PgUp/PgDn IB-specific key combination, freeing up the combination to do what it usually does in an editbox (extend the selection).

3) Remove Alt-PgUp/PgDn (current section scroll).

4) Remove the mapping of Ctrl-Home/End to section scroll (instead, it would then do the browser default of scrolling to the beginning/end of the document). (Note that in this patch, like Home/End it will only work when there is no text in the editbox).


As discussed on IRC, I don't think 1) is desirable as a default. But it would fit into an add-on, maybe with something that addresses your [2].

I personally wouldn't mind 2) but it does break an existing key combination, and means there won't be a keyboard way to page-scroll the browser when the editbox has focus, not sure how important that is for accessibility reasons. 

3) seems unneccessary. It's not a key combination that is used for anything else, so why not keep it, as you also say in [4].

4) See comment #6.
Comment on attachment 8352870 [details] [diff] [review]
Patch

*** Original change on bio 1234 attmnt 1126 at 2012-01-26 00:30:48 UTC ***

The code looks ok (switching the focus to the browser before dispatching the event and then switching the focus back seems a bit hackish, but I've nothing better to propose instead), let's try this on nightlies to see if people complain :).

By the way, thanks for caring about all these different situations/possibilities!
Attachment #8352870 - Flags: review?(florian) → review+
(Assignee)

Updated

5 years ago
Duplicate of this bug: 954300
(Assignee)

Updated

5 years ago
Duplicate of this bug: 954643
(Assignee)

Updated

5 years ago
Duplicate of this bug: 954304
*** Original post on bio 1234 at 2012-01-26 00:47:49 UTC ***

Checked in as http://hg.instantbird.org/instantbird/rev/3bc7b486f5bf

Thanks for fixing this up! If we have any other issues, we'll file follow up
bugs.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.2
Blocks: 954677
You need to log in before you can comment on or make changes to this bug.