-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Problems onMarkerClickListener #11795
Comments
I have the same problem. |
Thanks for reaching out and providing the examples, really appreciate that! Here is a reproducible example:
|
Bisecting reveals that the culprit is 7ce8588, this line to be precise. The issue happens only when @ChrisLoer or @ansis, would any of you mind taking this over? |
Yes, thanks everyone for the clear reporting and examples! I'm trying to get the reproduction case running (it usually takes me a while to get everything working on Android). While I work on that, two notes:
|
OK, I can reproduce locally on top of #11952, and I see now that it's reproducible over intervals much longer than 300ms. Investigating. |
Here's what's causing the problem:
You'll notice the problem goes away if you're zoomed in and you move the map to trigger some sort of collision detection. @ansis, the "don't commit unless opacity changes" logic keeps biting us in symbol querying. IIRC the reason you wanted to do it is that it saves us from a potentially unnecessary update of the opacity buffers. But the opacity updates are relatively cheap and this at most avoids one update every 300ms (and only on a map where nothing interesting is happening symbol-wise). We could add logic to prevent this particular problem, but it feels like it'll just make placement commit logic harder to follow -- I think I'd prefer to just remove the commit-skipping logic entirely. |
Can we expect this to be fixed in 6.2? |
This doesn't look like it will be a large fix, so I would expect that we get it in a patch or minor release pretty soon. |
Yep, this sounds like the right thing to do. It's not worth the complexity it adds. Should I open a pr or do you want to take this? |
Since placements will be committed even if they do not need the full fade duration to fade features in, we need the new `fadeStartTime` to keep track of how long we still need to fade. This is important because if we fade too long we will trigger another placement and never stop rendering.
Since placements will be committed even if they do not need the full fade duration to fade features in, we need the new `fadeStartTime` to keep track of how long we still need to fade. This is important because if we fade too long we will trigger another placement and never stop rendering.
I confirmed this is fixed with @ansis's changes in #12076. I got thrown off at first because the box for the query geometry in the repro case didn't actually match the viewport:
Height and width are reversed there... |
Since placements will be committed even if they do not need the full fade duration to fade features in, we need the new `fadeStartTime` to keep track of how long we still need to fade. This is important because if we fade too long we will trigger another placement and never stop rendering.
@ChrisLoer is there going to be a release with this fix included soon? |
Since placements will be committed even if they do not need the full fade duration to fade features in, we need the new `fadeStartTime` to keep track of how long we still need to fade. This is important because if we fade too long we will trigger another placement and never stop rendering.
@LukasPaczos any updates on the release timeline? We have updated to Mapbox 6 in order to use location layer plugin and this issue is blocking us from shipping a new version. Thanks! |
Hey @mahyarv, |
Updating my sdk version fixed this issue for me. Thanks! |
**Platform:Android
**Mapbox SDK version:6.0.1
Steps to trigger behavior
Expected behavior
onMarkerClickListener is fired
Actual behavior
Nothing happens on certain devices. I upgraded from the 5.2 version, but since the upgrade to 6.0.1, users with Huawai devices encounter problems when clicking a marker. Nothing happens when clicking a marker. I use this implmentation:
` map.setOnMarkerClickListener(new MapboxMap.OnMarkerClickListener() {
@OverRide
public boolean onMarkerClick(@nonnull Marker marker) {
The text was updated successfully, but these errors were encountered: