Skip to content
This repository was archived by the owner on Jan 2, 2025. It is now read-only.

Improvements to collection keyboard navigation #356

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

wolfgang42
Copy link
Contributor

Change

Fix collisions between browser shortcuts and comic next/previous navigation. See commit messages for full details.

Bug Fix – Fixes an issue with existing functionality

Context

Previously, keyboard modifiers (Ctrl/Alt/Meta) were ignored when looking up keyboard shortcuts. This made it impossible to use the browser's native ArrowLeftAlt/ArrowRightAlt shortcuts for history navigation, since the plugin would also perform navigation of its own on the same shortcuts.

Verification

  • I have read the code of conduct and contributing guidelines
  • I have followed the project's coding standards
  • I have added tests to cover all changes
  • I have verified that all new and existing tests pass
    (N/A, there don't seem to be tests for JS)
  • I have tested these changes on WordPress 5.7
    (as Vagrant provisioning seems to be broken, tested by replacing wp-content/plugins/webcomic/srv/collection/common.js with an unminified, modified version)
  • I have tested these changes on PHP 7.4.16
  • I have tested these changes in: Firefox 86, Chromium 89

Previously, keyboard modifiers (Ctrl/Alt/Meta) were ignored when looking
up keyboard shortcuts. This made it impossible to use the browser's native
ArrowLeftAlt/ArrowRightAlt shortcuts for history navigation, since the
plugin would also perform navigation of its own on the same shortcuts.

This commit fixes that problem by suffixing the `key` string with all
possible modifiers, so it won't match shortcuts with extra modifiers.
* Navigation starts slightly sooner, for improved perceived performance.
* When typing rapidly, users may roll over and release the modifier before
  releasing the modified key (but will never press the modified key before
  its modifier, since that doesn't work). Using keyup means that we may see
  the event after the user has already released the modifier; with keydown
  this is not the case.
* The browser also performs actions during the keydown event, so if we use
  the same event they can be intercepted to prevent the browser from taking
  actions of its own (this will be done in the next commit).
We fixed the problem for the default browser keybindings by checking for
all modifiers, but there's still the possibility that the user's browser
has some custom keybindings that conflict with ours. In this situation it
would probably be undesirable for the browser to also take its action, so
tell it that we've already handled the situation.
@wolfgang42
Copy link
Contributor Author

@mgsisk bump - LMK if there's anything you need from me on this

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant