[Unicode]   Common Locale Data Repository : Bug Tracking Home | Site Map | Search

CLDR Ticket #11218(closed: fixed)

Opened 8 months ago

Last modified 4 months ago

Feature request: Please remove tab navigation keyboard shortcuts in the survey tool

Reported by: fios@… Owned by: tbishop
Component: surveytool-other Data Locale:
Phase: dsub Review: srl
Weeks: Data Xpath:




Please remove the keyboard shortcuts for moving beween categories.

This is what happens:

You edit an entry and need to edit some existing text, e.g. by pressing backspace to remove a letter. Meanwhile in the background, the Survey Tool is still running some checks on the previous entry. Once the checks are done, the Survey Tool removes the focus from the current input field and reassigns it to the entry that just finished its checks.

If the user happens to be hitting the wrong key during text entry at the time, you end up with the previous or next category, and since the user sometimes hits more than one key in succession, the user ends up on a random category. You then have to remember which category you were in, find it again, then remember which entry you were in and scroll scroll scroll...

An alternative solution would be not to assign focus to entries when they finish their checks and recording the vote. That would be even more convenient.



Change History

comment:1 Changed 8 months ago by mark

  • Owner changed from anybody to tbishop
  • Priority changed from assess to major
  • Status changed from new to accepted
  • Milestone changed from UNSCH to 34

Goal should be to not change the focus when other items are refreshed.

Should be grouped together with the tickets where entering items too quickly causes problems.

comment:2 Changed 7 months ago by srl

  • Xref set to 11250 11246

comment:3 Changed 7 months ago by verdyp@…

Entering items "too quickly". In reality this is too much slowly (and still the time to wait is unpredicatable, sometimes even longer to avoid being disconnected automatically from the server.
This is a persistant problem (going now worse over time): there's lot of data to survey, it requires hours or days of persistant use to just fill a single screen (now about 25 seconds between each clic, most of the time being spent in a CPU intensive single thread on the browser which regenerates millions of DOM nodes; even on a fast machine with 8 cores at more than 3GHz, and 32GB of memory, installed on a SSD; the survey is unaccessible to most users)
I really suggest removing "automatic" refreshes, and use a single "submit" button on demand, or submitting if we change of screen by selecting another subset of data.

You should also reduce considerably the number of items displayed on the same screen so that refreshes takes much less time and are much less CPU intensive. The displayed survey table contains really too much data. it would also reduce the server load to query again and again most data that is unaffected by a single item submission.

comment:4 Changed 7 months ago by tbishop

This ticket refers to multiple related problems. A variety of solutions are suggested. I'm interpreting the main task to be to "remove tab navigation keyboard shortcuts" since that's in the title of the ticket and sounds relatively well-defined and achievable. The other proposed solutions might require some decisions about the user interface that I'm not qualified to evaluate or decide myself.

The problematic keyboard shortcuts are those that cause navigation to a different page. Backspace causes navigation to the previous page that the user was on, due to the default behavior of the browser, which maintains a history of pages visited. The left and right arrow keys cause navigation to the "previous" or "next" page, respectively, as defined by the order of pages defined by Survey Tool, NOT the browser's history.

This code is in redesign.js:

    $('body').keydown(function(event) {
    	if($(':focus').length === 0) {
    		if(event.keyCode === 37) {
    		} else if (event.keyCode === 39) {

This change seems to work:

   $('body').keydown(function(event) {
    	if($(':focus').length === 0) {
            if (event.keyCode === 8) { // backspace

It needs testing on all our supported browsers, both to test that backspace no longer mimics the back button, and also that backspace still works for editing.

Last edited 7 months ago by tbishop (previous) (diff)

comment:5 follow-up: ↓ 7 Changed 7 months ago by mark

Look at ticket:11265 when doing this one

comment:6 Changed 5 months ago by tbishop

I've successfully tested the above change on macOS localhost with Firefox, Chrome, and Safari. One thing I noticed this time is, before making the change, the bug didn't occur unless I first clicked outside the little input window, causing it to lose focus but not disappear. (The fact that the window doesn't disappear when you click outside it may be another bug, BTW.) Another thing is that the bug with the Backspace key only happened on Firefox.

I'm not currently set up to test on Windows localhost with Edge. I can take the time to set that up again, or commit and test on smoketest, which would be more efficient.

comment:7 in reply to: ↑ 5 Changed 5 months ago by tbishop

Replying to mark:

Look at ticket:11265 when doing this one

Ticket 11265 looks like a combination of this bug (11218, about backspace and arrow keys) and a different bug which I also noticed while working on 11211, in which the little input window disappears due to table elements being replaced in the DOM.

comment:8 Changed 5 months ago by tbishop

  • Component changed from unknown to survey

comment:9 Changed 5 months ago by tbishop

I committed changeset [14496] to trunk, will test on SmokeTest...

Version 0, edited 5 months ago by tbishop (next)

comment:10 Changed 5 months ago by tbishop

  • Status changed from accepted to reviewing
  • Review set to mark

comment:11 Changed 5 months ago by mark

  • Review changed from mark to srl

Resetting the reviewer to srl, since he'd be better at JS.

comment:12 Changed 4 months ago by srl

  • Status changed from reviewing to closed
  • Resolution set to fixed

Add a comment

Modify Ticket

as closed
Next status will be 'new'
Next status will be 'closed'

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.