I've set up a map with distance filter form. When the cursor is placed into the "search radius" input field and the user hits enter on the keyboard, it seems that the "my location" button click event is triggered. The form is set to use Ajax mode.
This behavior is quite disturbing and unexpected. Besides that, the filter is working (if not submitted via "enter", but using the submit button).
Any ideas what could be causing the interference?
Thanks,
Sebastian
What is the "search radius input field"?
In Toolset Maps, a Front End search will produce:
- a Distance Field ("Show results within")
- a Unit Field (KM/MI)
- a location field (the actual location)
Do you mean the "Distance Field" where you input the numeric KM/MI value?
If so, I just reported that a few days ago and this is the feedback I can pass along:
The "AJAX update when change in any filter value" means literally that: when any control changes its value. That works for the distance and also for the location.
The developer, however, agreed to search for better, combined methods, because the expected (user) behaviour is:
- you input a numeric KM value, and hit enter or any trigger of the search:
-- no results should be shown and a message should appear to also enter a location.
-- the search should not be triggered if no location is provided.
This will be looked into in a future development phase of Toolset.
For now, it's suggested to either not use AJAX, or wait for a fix, or communicate to your visitor through a Front End instruction how to use the Search (If AJAX is used)
Sorry - yes, I am talking about the distance input field. I've tried all different settings of "How do you want to update the results", but the behavior is always the same:
- user enters a search location (e.g. "Berlin, Germany")
- user keys in a distance (e.g. "100") and hits "return" (or the proceed button on a smartphone keyboard)
What happens:
- location input field changes to visitors gps coordinates
- distance resets itself to the default value (here 250)
- if set to auto-update, the map updates accordingly
You can reproduce here on the home page: hidden link
Any suggestions?
Thanks,
Sebastian
This is impossible unless you altered the code or added custom functionality.
The location cannot automatically switch to the current users' location because you must, in any case, get the user's approval to use his/her location.
And this is exactly what happens when I perform the steps you outline, it asks me if I want to share my location, and logically I do not.
I want to search for that centre I set manually.
This is working fine locally.
There must be a misconfiguration in your search or an alteration of the code or you added eventually some custom code to enhance the functionality.
What I suggest is to check if the issue also persists with a WordPress Default Theme and NO Plugins BUT the Toolset Plugins.
If not, re-enable the Plugins one after the other, and check the issue each time you enable a plugin.
Please report me when the issue comes back.
It might also be due to the Theme.
Please do reactivate your Theme only after you are sure the issue isn't coming from a 3rd Party Plugin.
Finally, if all this does not help, I suggest creating a new Dummy (simple) View, where you insert the Search with no alterations (just as it's inserted by the GUI) and check if you can replicate the issue on this new View.
When I try this locally, I cannot replicate it, but I may as well miss a step.
Please let me know the results so I can either advice the best solution, or if with the new details I will be able to replicate this, I will escalate it to the developers as a BUG.
I can confirm there are no customizations to the code or the functionality ?
Please try again in your test setup but following these steps:
- load the page in a new browser session
- answer "yes" if asked to allow access to geo location (because the visitor eventually wants to allow it, and the distance input field should work properly no matter if they allowed geolocation or not)
- then, type in a different location (e.g. "Berlin, Germany")
- type in a different distance (e.g. "100") and hit return
--> the location field is replaced with current coordinates
I've also created a fresh view, fresh page just for testing. Doesn't look nice but also shows the same error:
hidden link
Thanks,
Sebastian
I think I was able to see what you mean.
Here are the steps I needed to do in order to see the issue:
1. Create a few posts with addresses
2. Create a View that queries them and shows them on a map
3. The View has a custom search (no AJAX, just native settings) for distance
4. The website has an HTTPS protocol to allow "current user location" as well.
5. On the page with the View, I do:
- enter a distance value (and intuitively already hit "Enter", which already shows the error)
- or proceed to enter a location and hit enter (again I see the issue)
- or I click submit, then the issue does not happen.
So, it seems that this is correct as you stated it initially, the focus is on the "my location" and hitting enter fires that action connected to it.
The focus though, intuitively, should be on submit, probably.
I reported this.
Thank you for your patience, and I apologise I did not see the issue immediately.
Currently, a workaround I found is to put the "submit" button before the actual location search field.
(see screenshot)
This avoids the "Use my location" to be triggered by the enter, and even makes the "Location" field required before you can submit the search.
Hi Beda,
the real issue is that the "use my location action" is triggered as soon as the cursor is placed in the DISTANCE input field and the user hits RETURN.
Even if a city name/address has been picked from auto completion, and the distance value is changed afterwards, this strange behavior occurs and the location name is replaced by geo coordinates.
In which way is the keydown event of the "distance" field connected to the "my location" button, is there a way to release that connection?
Or to make the submit button the default action for a "return key" event?
Thanks,
Sebastian
Hi Beda,
after some more research I now understand your thoughts about repositioning the submit button. It seems the real problem is the fact that the "use my location" button is rendered as an html element "<button>". According to this thread the behavior with multiple buttons is not exactly defined and therefore browser dependent:
https://stackoverflow.com/questions/925334/how-is-the-default-submit-button-on-an-html-form-determined
It might help if the control could be implemented as another html element but the <button> element... moving the "submit" button to the beginning of the form is another, yet strange solution.
Thanks,
Sebastian
Toolset Maps 1.5 solves now this issue:
The Toolset Maps distance search on a map, when updated by AJAX "AJAX results update when visitors change any filter values", will work only if:
- you first enter the location, then the distance, and never hit ENTER but always just click on the Fields.
- you enter first distance OR location and then the other, but press ENTER each time.
If you, for example, happen to enter the distance first, then you CLICK (not enter) into the Location field, and fill that out too, and then click outside that field or even just pick from the auto-suggested location (it still/already triggers the search), the results will be not properly updated (all entries are shown instead).
So in the broken version of Maps you could use the Distance Filter with "AJAX results update when visitors change any filter values" working only if the user is perfectly aware to use ENTER each time, or you add a Submit button.
This is now solved in 1.5
The usability issue/request about "Require the Location Field, if it's empty and a distance is submitted to the search query" is still under review.
This last remaining "issue" means, that the sentence "AJAX update when change in any filter value" literally means: when ANY control changes its value.
That works for the distance and also for the location.
We might be able to introduce another concept to adjust that, but it will demand time and planification.
Hence, we can close this ticket if you agree.