Bug #2016

Menu search box misses chars if user types too slow

Added by Stefano Fancello about 8 years ago. Updated over 7 years ago.

Status:CLOSEDStart date:
Priority:NormalDue date:
Assignee:-% Done:

100%

Category:nethserver-nethgui
Target version:v6.5-beta3
Security class: Resolution:
Affected version:v6.4-beta1 NEEDINFO:No

Description

When typing in search box, if you type too slow, searching starts before you stopped tying and when it's searching, typed chars is lost
It seems that a search start when user stop typing for ~1 second, if for instance user type "net" and wait a little time, when type "work" search box could have something like "netork" in it. Expected behaviour is that when you type something, interface start searching continuing to accept user inputs

Related issues

Related to Nethgui - Task #940: Menu search "as you type" CLOSED 03/29/2012

Associated revisions

Revision 143d8afc
Added by Davide Principi over 7 years ago

Menu UI module: cancel pending XHR before sending a new one. Refs #2016

Revision 9b969167
Added by Davide Principi over 7 years ago

Trigger search only if an alfanumeric character is typed. Refs #2016

History

#1 Updated by Davide Principi about 8 years ago

  • Subject changed from Search box in nethserver gui miss chars if user type too slow to Menu search box misses chars if user types too slow
  • Priority changed from Low to Normal
  • Target version set to v6.4-beta2
  • Affected version set to v6.4-beta1
  • NEEDINFO changed from No to Yes

Hi Stefano, please confirm: expected behaviour is

  1. user starts typing in search box (we must consider a very low frequency)
  2. after period (currently 600ms) has elapsed the AJAX query (say Q1) starts but UI does not freeze (another visual-feedback must appear)
  3. user keeps on typing
  4. another period has elapsed: we must wait for Q1 completion. When Q1 has finished (and the list has been filtered), a second AJAX query (say Q2) starts

#2 Updated by Stefano Fancello about 8 years ago

  • Priority changed from Normal to Low

Yes. But on 4th point I think that Q1 results are useless when a Q2 request is ready, so, if it is possible on implementation side to start Q2 without waiting for Q1 and drop Q1 results, it would be better.
This is because if you keep accepting user inputs when Q1 is started and Q1 is significantly slow (> 600ms) Q2 starts before Q1 has returned and user would have visual feedback from Q2, but menu is the results of Q1.

#3 Updated by Davide Principi about 8 years ago

  • Status changed from NEW to TRIAGED
  • Priority changed from Low to Normal
  • % Done changed from 0 to 20
  • Estimated time set to 2.00
  • NEEDINFO changed from Yes to No

Stefano Fancello wrote:

start Q2 without waiting for Q1 and drop Q1 results

Ok, this is feasible. We can abort() Q1 and start Q2 immediately.

Note about this bug priority: this is not blocking nor urgent, but must be surely fixed before beta2 release, so I set it to normal.

#4 Updated by Giacomo Sanchietti almost 8 years ago

  • Target version changed from v6.4-beta2 to v6.5-beta3

#5 Updated by Giacomo Sanchietti almost 8 years ago

  • Target version changed from v6.5-beta3 to v6.4-beta2

#6 Updated by Giacomo Sanchietti almost 8 years ago

  • Affected version changed from v6.4-beta1 to v6.5-beta3

#7 Updated by Giacomo Sanchietti almost 8 years ago

  • Target version changed from v6.4-beta2 to v6.5-beta3
  • Affected version changed from v6.5-beta3 to v6.4-beta2

#8 Updated by Davide Principi almost 8 years ago

  • Affected version changed from v6.4-beta2 to v6.4-beta1

Process note
I would keep "Affected version" to the original value, treating it as a read-only field. It suggests when the problem arose.

#9 Updated by Davide Principi over 7 years ago

  • Status changed from TRIAGED to ON_DEV
  • Assignee set to Davide Principi
  • % Done changed from 20 to 30

#10 Updated by Davide Principi over 7 years ago

  • Status changed from ON_DEV to MODIFIED
  • Assignee deleted (Davide Principi)
  • % Done changed from 30 to 60

Test case

After upgrading, the screen is not frozen while an XHR is pending, thus more characters can be typed.

Only letters and digits trigger an XHR, and abort any pending request, if exists.

#11 Updated by Davide Principi over 7 years ago

  • Status changed from MODIFIED to ON_QA
  • % Done changed from 60 to 70

In nethserver-testing:
nethserver-nethgui-1.3.0-10.0git9b969167.ns6.noarch.rpm

#12 Updated by Davide Principi over 7 years ago

  • Target version deleted (v6.5-beta3)

#13 Updated by Giacomo Sanchietti over 7 years ago

  • Assignee set to Giacomo Sanchietti

#14 Updated by Giacomo Sanchietti over 7 years ago

  • Status changed from ON_QA to VERIFIED
  • Assignee deleted (Giacomo Sanchietti)
  • % Done changed from 70 to 90

Test with slow and fast typing: no errors encountered.

Marking as VERIFIED.

#15 Updated by Davide Principi over 7 years ago

  • Status changed from VERIFIED to CLOSED
  • % Done changed from 90 to 100

Released in nethserver/6.5/base repository.

Also available in: Atom PDF