Make WordPress Core

Opened 7 years ago

Last modified 2 years ago

#38211 assigned defect (bug)

Interference of AJAX search with input field auto-complete

Reported by: armandsdz's profile armandsdz Owned by: adamsilverstein's profile adamsilverstein
Milestone: Future Release Priority: normal
Severity: normal Version: 4.6
Component: Plugins Keywords: ux-feedback uniform-search has-patch needs-testing
Focuses: ui, accessibility Cc:

Description

In WordPress 4.6 new feature was introduced in "Add Plugin" page - user input in "Search Plugin" field triggers AJAX search. That's great but it also makes browser's auto-complete of this field to disappear (at least in Chrome).
Therefore it's difficult to select an already existing option of plugin name that browser's auto-complete offers because AJAX search gets triggered very soon after you type a letter in input field.
So, in most cases I need to type full name of the plugin or try to select auto-complete option before AJAX gets triggered.

I'm not sure what the solution for this would be but I don't think it's difficult to press Enter or tap Search button after you have written everything you wanted without system interfering with the process without user wanting it.
In addition, the fact that button Search disappeared some time ago made it impossible to add a plugin on touch devices. I see that AJAX search perhaps tries to fix this but it breaks auto-complete as I mention above.

Attachments (6)

38211.diff (995 bytes) - added by adamsilverstein 7 years ago.
Add autocomplete="off" to the new plugin search (ajax) field
38211.2.diff (1.9 KB) - added by adamsilverstein 7 years ago.
38211.3.diff (2.2 KB) - added by adamsilverstein 7 years ago.
38211.4.diff (3.1 KB) - added by adamsilverstein 4 years ago.
38211.5.diff (3.1 KB) - added by adamsilverstein 3 years ago.
38211.6.diff (3.4 KB) - added by adamsilverstein 2 years ago.

Download all attachments as: .zip

Change History (44)

#1 @armandsdz
7 years ago

  • Keywords ux-feedback added

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


7 years ago

#3 @afercia
7 years ago

  • Milestone changed from Awaiting Review to Future Release

Right, I guess this is the reason why other, similar inputs used for "live searches" have an autocomplete="off" attribute. Definitely something to have a look into.

#4 @afercia
7 years ago

  • Keywords uniform-search added

Related: #31818

@adamsilverstein
7 years ago

Add autocomplete="off" to the new plugin search (ajax) field

#5 @adamsilverstein
7 years ago

In 38211.diff I added the autocomplete="off" property we have on other ajaxified search fields. @armandsdz I'm not sure this really helps your issue because with this patch you are left without autocomplete; what it does solve is the conflicted interaction between autocomplete and ajax search. Can you review/test to see if you find this helpful?

#6 @mklusak
7 years ago

Oh yes, this feature drives me crazy! Searching for my favourite plugins became irritating experience - I start typing name of plugin, browser shows autocomplete list of older inputs, I hit down arrow to select the desired, ... aaaaand search is triggered. I would love to deactivate this awesome search feature, but can't find anything.

#7 @afercia
7 years ago

See also related: ticket:37233#comment:21

ideally it should trigger after 2 ASCII chars or one high UTF-8 char. We can standardize this for all similar cases in core, there are at least 6-7 other places.

#8 @johnbillion
7 years ago

#38516 was marked as a duplicate.

#9 @johnbillion
7 years ago

  • Keywords has-patch needs-testing added

#10 @afercia
7 years ago

#39450 was marked as a duplicate.

#11 @adamsilverstein
7 years ago

38211.2.diff

  • Add autocomplete="off" to plugin list table search field which is also ajaxified

#12 follow-up: @finalwebsites
7 years ago

It would help if the live-search feature would start searching after entering 3 or more characters. Or better give the user an option to enter a number of minimum chars.
The problem is not the autocomplete feature, the live-search starts to fast (after entering a single character)

#13 in reply to: ↑ 12 @armandsdz
7 years ago

Great observation!
That is probably the thing that is annoying - that everything starts to move and search as soon as you enter the first character.
In addition, when I enter, for example, "w", it starts the search and return no results.
If search would be triggered after three or so characters, user would have a chance to choose something from auto-complete list if desired. Or just finish typing what's intended.

In essence, at this point this ajax search is not fast and not unobtrusive enough to be ok that it gets triggered so early.

Replying to finalwebsites:

It would help if the live-search feature would start searching after entering 3 or more characters. Or better give the user an option to enter a number of minimum chars.
The problem is not the autocomplete feature, the live-search starts to fast (after entering a single character)

#14 follow-up: @adamsilverstein
7 years ago

I agree, we should delay starting the search until the user has typed two or three letters. We do that elsewhere and we should match that logic here. I still think autocomplete should be disabled for the field because ajax search and autocomlete will still visually interfere with each other once the ajax search kicks in.

#15 in reply to: ↑ 14 ; follow-ups: @finalwebsites
7 years ago

Replying to adamsilverstein:

I still think autocomplete should be disabled for the field because ajax search and autocomlete will still visually interfere with each other once the ajax search kicks in.

You can keep the autocomplete function because the form element doesn't show any ajax content. So it wouldn't interfere and it will help the user who is installing plugins for multiple websites.

#16 in reply to: ↑ 15 @mklusak
7 years ago

Replying to finalwebsites:

You can keep the autocomplete function because the form element doesn't show any ajax content. So it wouldn't interfere and it will help the user who is installing plugins for multiple websites.

I agree! For me the autocomplete function on that field is much more important than the ajax search.

#17 in reply to: ↑ 15 ; follow-up: @adamsilverstein
7 years ago

You can keep the autocomplete function because the form element doesn't show any ajax content. So it wouldn't interfere and it will help the user who is installing plugins for multiple websites.

Do you mean until the user types 3 characters and the ajax results fire?

#18 follow-up: @adamsilverstein
7 years ago

  • Owner set to adamsilverstein
  • Status changed from new to assigned

38211.3.diff Is an alternate approach that limits searching until you type at least 2 characters, and dynamically removes the autocomplete attribute before the ajax search kicks in. We use a similar approach in nav-menus.js.

This gives you one character to type in and see/select autocomplete results, once you hit 2 characters, the ajax search kicks in and autocomplete has been disabled for the field. You can override the threshold by setting wp.updates.searchMinCharacters after the JS loads.

@mklusak & @finalwebsites & @armandsdz can you test this out and see what you think?

  • add a new variable developers can adjust, defaults to 2: wp.updates.searchMinCharacters = 2;
  • leave autocomplete enabled for search field until user types searchMinCharacters - 1 (right before ajax search kicks in)
  • only perform ajax search when searchMinCharacters reached. also re-search on empty field so if suer clears field results are reset
Last edited 7 years ago by adamsilverstein (previous) (diff)

#19 in reply to: ↑ 17 @finalwebsites
7 years ago

Replying to adamsilverstein:

You can keep the autocomplete function because the form element doesn't show any ajax content. So it wouldn't interfere and it will help the user who is installing plugins for multiple websites.

Do you mean until the user types 3 characters and the ajax results fire?

I think you can keep autocomplete anyway. The ajax result becomes visible on a complete different place. The search field doesn't have any Ajax function. That's why you need to change it.

#20 in reply to: ↑ 18 @finalwebsites
7 years ago

Replying to adamsilverstein:

38211.3.diff Is an alternate approach that limits searching until you type at least 2 characters, and dynamically removes the autocomplete attribute before the ajax search kicks in. We use a similar approach in nav-menus.js.

This gives you one character to type in and see/select autocomplete results, once you hit 2 characters, the ajax search kicks in and autocomplete has been disabled for the field. You can override the threshold by setting wp.updates.searchMinCharacters after the JS loads.

@mklusak & @finalwebsites & @armandsdz can you test this out and see what you think?

  • add a new variable developers can adjust, defaults to 2: wp.updates.searchMinCharacters = 2;
  • leave autocomplete enabled for search field until user types searchMinCharacters - 1 (right before ajax search kicks in)
  • only perform ajax search when searchMinCharacters reached. also re-search on empty field so if suer clears field results are reset

I tried this patch but the live search is still searching after I entered the first character. It takes a second now before something happens. In my opinion the code is missing that limits the search for the searchMinCharacters var.

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


6 years ago

#22 @melchoyce
6 years ago

@adamsilverstein Still interested in working on this?

#23 @adamsilverstein
6 years ago

Yes, thanks for the reminder - I will take another look. I think the code is correct, so not sure why @finalwebsites said "is still searching after I entered the first character." - I'll give this another test and post a screencast to show the behavior I am seeing.

#24 @afercia
6 years ago

It would be nice to be consistent in all the "live" searches, for example trigger a search after 2 chars have been entered also in the themes search. For some recent changes there, see [42029] which fixed a small regression introduced in [41797].

#25 @finalwebsites
6 years ago

Hi,
the search experience for the plugin search is still not amazing. But I learned to live with that :)
Please check my screenshot, it shows that the search starts right after I entered the first character (not sure if the current WP version has change for this).

https://www.dropbox.com/s/yauhxowm2khpxj8/Screenshot%202017-11-06%20at%2019.51.37.png

For a non-ajax search would work much better. The Ajax search is slow and isn't a great user experience (my opinion).

#26 @mklusak
6 years ago

I confirm @finalwebsites words ... the "one letter starts AJAX search" behavior is still there and it is really annoying. It drives me crazy! :-)

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


6 years ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


5 years ago

#29 @adamsilverstein
4 years ago

  • Milestone changed from Future Release to 5.4

#30 @adamsilverstein
4 years ago

38211.4.diff

  • refresh against trunk
  • when typing more than [min characters], then deleting some characters (eg type 3 characters then delete 1), still perform search so display is reset.
  • clean up doc blocks

This ticket was mentioned in Slack in #accessibility by audrasjb. View the logs.


4 years ago

This ticket was mentioned in Slack in #accessibility by audrasjb. View the logs.


4 years ago

#33 @karmatosed
4 years ago

  • Milestone changed from 5.4 to Future Release

As beta 1 is today, going to move this to future milestone.

#34 @SergeyBiryukov
4 years ago

#49880 was marked as a duplicate.

#35 @Mista-Flo
4 years ago

The patch can still be applied to trunk, @SergeyBiryukov I would consider moving it to 5.6 milestone. FYI @audrasjb

This ticket was mentioned in PR #969 on WordPress/wordpress-develop by adamsilverstein.


3 years ago
#36

Trac ticket:

#37 @adamsilverstein
3 years ago

38211.5.diff is a refresh against trunk.

#38 @adamsilverstein
2 years ago

38211.6.diff is a refresh against trunk

Note: See TracTickets for help on using tickets.