- bind noscroll variants of move article hotkeys to n/p by default
- update N/P (i.e. scroll article content) hotkeys to scroll by fraction of viewport height instead of hardcoded pixel distance
- minor fixes w/ checking for undefined
1. instead of jumping/scrolling sometimes, always scroll by a constant viewport offset unless moving to next/prev article directly
2. when going up and current article is partially above the viewport, move to its top first instead of directly to a previous one
3. instead of previous marking active logic, on scroll in combined mode track first (partially or otherwise) visible article as active
1. invoke Headlines.loadMore() if last article row is close to becoming visible instead of relying on headlines-spacer offset to viewport
2. allow one final last lazy load request if incomplete buffer was received to permit some flexibility with unread counters possible changing while request was generated / serving remainder of articles
This change introduces derived classes for ComboButton, DropDownButton
and Select that make sure that buttons do not remain focused after their
menus are closed. This allows using hotkeys after closing them.
Since making use of keypress in addition to keydown, hotkeys did not
work in certain scenarios, including clicking on the feed tree expanders
or empty spaces of the toolbar.
This issue is caused by dijit.Tree and dijit.Toolbar implementing the
_KeyNavMixin, which explicitly stops propagation of keypress events.
This change contains two main fixes plus a smaller hotfix:
1. It overrides _onContainerKeydown and _onContainerKeypress for
fox.FeedTree (which inherits from dijit.Tree).
2. It adds fox.Toolbar, which overrides _onContainerKeydown,
_onContainerKeypress and focus. This fixes hotkeys being swallowed
and the first focusable child receiving focus when clicking on an
empty space of the toolbar.
3. It adds the same handling of keydown and keypress to the prefs hotkey
handler as is done in the main hotkey handler.
keydown returns the "raw" key in event.which. Depending on the keyboard
layout, this may not be what is wanted. For example, on a German
keyboard, Shift+7 has to be pressed to get a slash. However, event.which
will be 55, which corresponds to "7". In the keypress event, however,
event.which will be 47, which corresponds to "/".
Sadly, several important keys (such as escape and the arrow keys) do not
trigger a keypress event. Therefore, they have to be handled using a
keydown event.
This change refactors the hotkey support to make use of keypress events
whenever possible. This will make hotkeys work regardless of the user's
keyboard layout. Escape and arrow keys are still handled via keydown
events.
There should be only one change in behavior: I could not make Ctrl+/
work and therefore rebound the help dialog to "?".
Andrew Dolgov