Repository navigation
GoogleMap.OnInfoWindowCloseListener is missing from MarkerManager.Collection #1540
Description
MarkerManager documentation claims (emphasis mine):
Keeps track of collections of markers on the map. Delegates all Marker-related events to each collection's individually managed listeners.
However notably one OnInfoWindowCloseListener, also a marker related event and the only one not covered, isn't handled by MarkerManager (and consequently ClusterManager and related).
In #750 we added OnInfoWindowLongClickListener but the close listener wasn't included.
Activity
googlemaps-bot commentedon Dec 9, 2025
🎉 This issue has been resolved in version 3.20.0 🎉
The release is available on:
v3.20.0Your semantic-release bot 📦🚀
bshi commentedon Dec 9, 2025
@dkhawk I believe #1636 is necessary but not sufficient to resolve the broader issue. ClusterManager (a dependent of MarkerManager) also needs updates (done in #1541)
Furthermore, as mentioned in the commit msg for #1541, these are technically breaking changes as anyone that upgrades from, e.g. 3.19.0 to 3.20.0 and also uses these events will now have conflicting setters.
kikoso commentedon Dec 9, 2025
Hi @bshi . Thanks for the comment!
When you mention a breaking change, this would be if these events have been handled in a custom renderer, correct? #1636 introduces two public methods that do not affect previous versions of the library. IMO a breaking change would happen if the library already provides those setters.
On the other message: you are correct, #1541 introduces functionality that needs to be implemented, otherwise the ClusterManager (and hence, the renderers) are not implementing the listeners. This is included in #1541, but I believe now there will be a conflict after merging #1636 (both PRs add this bit of functionality, but in a different order).
Would it be possible for you to rebase main onto #1541? Then IMO can be merged (and this is correctly marked as a breaking change)
bshi commentedon Dec 9, 2025
I believe #1636 is also broken because it does not properly register the new listener during setup. That's why this kind of change is backward compatible. My recommendation would be to revert #1636 until more robust QA/testing can be done.