Assigned
Status Update
No update yet.
Comments
ca...@google.com
ca...@google.com
Thank you for posting.
We are currently looking into this and will get back to you as soon as we have an update.
ca...@google.com
Thanks for your suggestion!
We'll be reviewing this for further consideration. Please star this issue to get updates and leave comments for additional information. Please note that starring the issue also provides our product team with valuable feedback on the importance of the issue to our customers.
jh...@google.com
Hi there OP, "places_changed" isn't quite the right event to detect users attempting to abandon the place selection. Could your implementation work with other events for this purpose?
ms...@ivalua.com
Hi,
thank you,
There are two needs :
- (I) if "place_changed" is detected, we need to know what was the
original (source) user-action that fired "place_changed" which could be
something like :
- mouse click : inside the "*pac-container*" on any returned google
prediction,
- mouse click : *outside the "pac-container",*
- Tab-key pressed,
- Enter-key pressed,
- or eventually, any other user source-event,
- (II), the second need is to have your definition of what could be
considered as "Place_Selection_Abandoned" event :
- Which user-action, you will consider, for firing this eventual
event of "place selection Abandon" ?
- If even when clicking outside the "*pac-container*", you don't fire
this new "*Place_Selection_Abandoned*", but instead, you fire as for
now, "*place_changed*", the issue will just remain as it is now.
As for now, place_changed is fired even when user clicks outside the
"pac_container". Which is strange as UX behavior.
So, if you change place_changed event so that it doesn't fire when clicking
outside the "pac_container", it could be a solution.
Another solution, is to let place_changed firing even when clicking outside
the "pac_container", but you add some data to the Event Handler Arguments,
so we can know that user effectively clicked outside the "pac_container",
and we can though, in our custom code, forgive this place_changed event for
this case, and we don't take account of the address coming out.
best regards
On Wed, Nov 8, 2023 at 12:04 PM <buganizer-system@google.com> wrote:
thank you,
There are two needs :
- (I) if "place_changed" is detected, we need to know what was the
original (source) user-action that fired "place_changed" which could be
something like :
- mouse click : inside the "*pac-container*" on any returned google
prediction,
- mouse click : *outside the "pac-container",*
- Tab-key pressed,
- Enter-key pressed,
- or eventually, any other user source-event,
- (II), the second need is to have your definition of what could be
considered as "Place_Selection_Abandoned" event :
- Which user-action, you will consider, for firing this eventual
event of "place selection Abandon" ?
- If even when clicking outside the "*pac-container*", you don't fire
this new "*Place_Selection_Abandoned*", but instead, you fire as for
now, "*place_changed*", the issue will just remain as it is now.
As for now, place_changed is fired even when user clicks outside the
"pac_container". Which is strange as UX behavior.
So, if you change place_changed event so that it doesn't fire when clicking
outside the "pac_container", it could be a solution.
Another solution, is to let place_changed firing even when clicking outside
the "pac_container", but you add some data to the Event Handler Arguments,
so we can know that user effectively clicked outside the "pac_container",
and we can though, in our custom code, forgive this place_changed event for
this case, and we don't take account of the address coming out.
best regards
On Wed, Nov 8, 2023 at 12:04 PM <buganizer-system@google.com> wrote:
va...@gmail.com
Hey, I'm having some serious problems regarding this issue. I need the click event inside the pac-container not to propagate to the rest of the DOM when user selects a place from the autocomplete. I've been trying for hours to come up with a solution and I can't find one.
sa...@tredder.com
For my use case, I do not see any 'place_changed' event if the user starts typing and then hits tab.
I do see if they type some random text and hit return I get back {name: 'random text'} instead of google.maps.places.PlaceResult, but if they hit "tab" no event is received.
I'd like to be able to catch when the user has hit "tab" in this case, and be able to expose a message saying they need to select an address.
I do see if they type some random text and hit return I get back {name: 'random text'} instead of google.maps.places.PlaceResult, but if they hit "tab" no event is received.
I'd like to be able to catch when the user has hit "tab" in this case, and be able to expose a message saying they need to select an address.
sa...@tredder.com
*I should caveat that this is if the user hits tab before using the arrows to navigate the suggested addresses popdown menu.
Description
Using SearchBox or Autocomplete widgets, we noticed a miss in argument details.
Our code is something easy like following :
//*
autocomplete = new google.maps.places.SearchBox(input);
autocomplete.addListener("places_changed", function (e) {
onPlacesChangedOnSearchBox(phcAdrId);
});
*//
We miss in the arguments of place_changed event some details like the original end-user event that fired the "place_chaged" event.
This original event could be :
- mouse click : inside the "pac-container" on a special prediction, or totally outside it,
- tab key pressed,
- or, enter key pressed,
The only way to abandon place selection after displaying predictions in your widgets, is ESC as I know.
In our solution, we would like to abandon place selection also, when the user clicks outside the "pac-container" in any other place in the page, when no prediction is chosen or selected by the user.
Please could you help us find a solution for this purpose ?
Regards