Annotation click doesn't consume map click

[mar-v-in]

Currently when clicking an annotation, this will trigger the annotation click event without consuming the map click event. I would assume the annotation manager to consume the map click event if it already invoked an annotation click listener, so that the map click event isn't invoked for any map element that is below the annotation (as most likely, the user didn't click anything below the annotation, but really the annotation itself).

[LukasPaczos]

Hey @mar-v-in, we can't consume events in the plugin, otherwise, there'd be no way to register other listeners after the plugin has been initialized. See #815.

[mar-v-in]

@LukasPaczos My proposal would be to only consume the event if a marker click listener was invoked, which means the click happened on a marker and a marker click listener is registered. In all other cases the event would not be consumed so other listeners can use it. The rationale behind this is that the user doesn't actually click the map, but the annotation. I think this is also the same behavior other Maps APIs chose.

I am currently porting an app from Google Maps API to Mapbox SDK and noted this slight difference in behavior, which in my case caused the app to become unusable as a marker click was used to activate the marker and a map click to deactivate the current marker. As both happen on Mapbox SDK, the markers became not activatable (as they are activated and deactivated at the very same time). My current workaround is to ignore map click event for deactivation if it happens at the location of any marker.

[LukasPaczos]

Thanks @mar-v-in, I think the proposed behavior is rational. Additionally, we could make AnnotationClickListeners return booleans as well and consume the upstream click callback only if one of the downstream listeners consumes it.

[mar-v-in]

Additionally, we could make AnnotationClickListeners return booleans as well and consume the upstream click callback only if one of the downstream listeners consumes it.

Agree, this is probably the best thing to do here, but it would create an API incompatibility, so is only an option for a major version bump.

[LukasPaczos]

Plugins are designed for quick iterations and are all on the 0.x versions, which doesn't rule out breaking changes in the APIs by the semantic versioning rule book.

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[stale]

This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.