Globe: Marker and Feature-Click-Box diverge between zoom level 5 and 6 --> marker clicks impossible
mapbox-gl-js version: 2.15.0 and 3.1.2
browser: All
Steps to Trigger Behavior
- Scroll map to zoom between 5 and 6
- .. watch the marker icon and featureBox diverge. more pronounced the bigger the screen is, and the more the marker wander to the edges of the screen.
map.showCollisionBoxes = trueso the behaviour is visible. - user cannot click the marker anymore as the clickbox (aka featurebox) has wandered way off
Link to Demonstration
-> 📺 screenrecording
Expected Behavior
Map zooms fluidly across all zoom levels, the (custom) icons/markers remain at their intended position on the globe. And icon/marker is bound (fixed) with the click/featurebox. they should be one and exactely the SAME.
Actual Behavior
current actual broken behaviour: between zoom 5 and 6 the globe exhibits wrong behaviour regarding markers and their click areas.
in globe_util.js
export const GLOBE_ZOOM_THRESHOLD_MIN = 5;
export const GLOBE_ZOOM_THRESHOLD_MAX = 6;
sets the transition from globe to mercator projection. a really nice effect, visually, and it works well and fluid. the markers stay put where they should be. (there were other older issues, where this wasn't the case.. but they are fixed now) my issues is: on a sufficiently large screen, where eg. zoom 5.85 still leaves substantial area of the map visible, the marker and clickbox diverge. the marker is NOT clickable anymore. that happens on a regualr 13' macbook, and is even more pronounced on a 24' 4K screen. (with such a monitor i recorded the screencast) so when both the marker and clickbox diverge then a click on "the marker" wont yield anything. (no popup/ no clustering..)
const selectedFeatures = map.queryRenderedFeatures(bbox, {
layers: layersToSearchFor
});
returns [] , there is simply no feature below the marker. 💥
it has 'wandered' off.
see screenrecording for the detailed visual behaviour.
happy to provide more details if i left something unclear.
ps: i spent a considerable amount of time investigating this error.
i followed the contributing guide and installed mapbox locally and i ran the develop/debug version, tried to locate the spots where marker and the feature box get set. but unfortunately to no avail. there is such a plethora of files involved. i simply could not follow. it must happen somewhere in the painter, globe-utils, transform and symbol-layout, i guess.
respect goes out to @mourner @karimnaaji and the many many more who have coded such a marble which works so great and is built and powered by so much math and abstractions. just reading the codebase gives a glimpse only into this whole universe!
that said, potentially it is a one line fix, as the marker itself (=the icon) stays already nice and put in the "transition zone" in zoom 5 to 6. so basically the clickbox shouldn't even be calculated separately but stay in sync(= identical) with the marker itself, and can simply reuse the logic/calc as it is done for the marker position. so far to my naive ideas, without knowing the history and codbease involved in [currently] having two different calculations paths here.
This issue is on the surface merely a cosmetic superficial problem, i know. But hey, it is a bug nonetheless, as @stepankuzmin added the bug label to it. Half a year ago. Is there any chance this gets put on a list of things to fix which a future update will remedy? Or did you folks fixed it already and simply forgot to reference it somewhere?
Glad to get some sort of insight into this. Thank you!
Any update on this bug?
Hey @stepankuzmin is there a ETA for fixing this one? Thank you.
I just reached out to payed MapBox Technical Support and only got a copy&pasta reply saying I should check here, I didn't really expect much more to be honest, but unfortunately, there has not been any update in a long time on this issue either. Would be great to know if there is at least a workaround for this?
@stepankuzmin is there a workaround for this bug and/or an ETA when this will be worked on/fixed?
Thank you.
Is there any update to this issue or a plan when this might get addressed @stepankuzmin ?