Skip to content

Set ordering for input gesture identifiers is unreliable #6945

@jcsteh

Description

@jcsteh

We want input gesture identifiers with multiple items of indeterminate order (e.g. multiple keys) to be handled the same way regardless of the ordering of the items. For example, control+shift+f1 should be treated the same as shift+control+f1. To do this, we currently normalise using Python set order. My original thinking was that the output order needs to be consistent regardless of the input order, but it doesn't need to make sense to humans. Set order seemed like an ideal solution, since there's no sorting cost. Unfortunately, while this is often true for set ordering, it isn't true when there are hash bucket conflicts. For example:

>>> # Case 1: The output order is consistent regardless of input order.
>>> {1, 2}
set([1, 2])
>>> {2, 1}
set([1, 2])
>>> # Case 2: The output order is different for different input orders.
>>> {8, 256}
set([8, 256])
>>> {256, 8}
set([256, 8])

(See this StackOverflow thread for details.)

The specific example for case 2 is actually seen in the wild; it is the cause of #3157 (comment). The fact that we haven't seen this elsewhere is just luck. For example, you can reproduce it as follows:

  1. Open the Python console.
  2. Enter the following: import globalCommands; globalCommands.commands.bindGesture("kb:control+windows+f1", "dateTime")
  3. Try pressing control+windows+f1 in input help.
  • Expected: Date time command.
  • Actual: Nothing.

To fix this, we're going to need to use some other ordering. Sorting for every gesture identifier seems expensive. This is also going to be painful because all the existing implementations output in set order; they don't call a common normalisation function.

CC @michaelDCurran.

Metadata

Metadata

Assignees

No one assigned

    Labels

    p3https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions