Opened 8 years ago
Closed 3 months ago
#38211 closed defect (bug) (fixed)
Interference of AJAX search with input field auto-complete
Reported by: | armandsdz | Owned by: | adamsilverstein |
---|---|---|---|
Milestone: | 6.7 | Priority: | normal |
Severity: | normal | Version: | 4.6 |
Component: | Plugins | Keywords: | uniform-search has-patch commit |
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 (8)
Change History (50)
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
8 years ago
#5
@
8 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
@
8 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
@
8 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.
#12
follow-up:
↓ 13
@
8 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
@
8 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:
↓ 15
@
8 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:
↓ 16
↓ 17
@
8 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
@
8 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:
↓ 19
@
8 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:
↓ 20
@
8 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
#19
in reply to:
↑ 17
@
8 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
@
8 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.
7 years ago
#23
@
7 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.
#25
@
7 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).
For a non-ajax search would work much better. The Ajax search is slow and isn't a great user experience (my opinion).
#26
@
7 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.
7 years ago
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
6 years ago
#30
@
5 years ago
- 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.
5 years ago
This ticket was mentioned in Slack in #accessibility by audrasjb. View the logs.
5 years ago
#33
@
5 years ago
- Milestone changed from 5.4 to Future Release
As beta 1 is today, going to move this to future milestone.
#35
@
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.
4 years ago
#36
Trac ticket:
#37
@
4 years ago
38211.5.diff is a refresh against trunk.
#38
@
3 years ago
38211.6.diff is a refresh against trunk
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
3 months ago
#40
@
3 months ago
- Milestone changed from Future Release to 6.7
For consistency, this really needs to get done. I don't see a sound reason to keep this search input different from other AJAX searches. Milestoning for 6.7. Happy to own, if you don't want to keep this @adamsilverstein
#41
@
3 months ago
- Keywords commit added; ux-feedback needs-testing removed
Updated patch updates the @since reference and changes the comparison logic for previousSearchStringLength
to >
instead of >=
so that a transition from 2 characters to 1 character does not trigger the AJAX query.
Tested; works as expected:
1) No autocomplete feedback after AJAX fires.
2) Query only fires when there are two or more characters in the query, whether characters are added or removed.
Marking for commit.
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.