[regression] 0.44.0 map.queryRenderedFeatures() completely ignores symbols

[mike-marcacci]

Upon upgrading to 0.44.0, map.queryRenderedFeatures() fails to return any symbol layers that use GeoJSON sources specified in the second argument. I've gone through my layers' layout properties one-by-one to see if there is one particular trigger, and there doesn't seem to be.

Do note, though, that rarely map.queryRenderedFeatures will return a symbol layer, but after just another second of map interaction, stops again. Downgrading to 0.43.0 fixes this.

VIEW SCREENCAST

Check out #6075 for a screencast of "expected" behavior.

[pathmapper]

Running into the same issue with overzoomed vector tile sources hosted by Mapbox.

Steps to reproduce using this jsfiddle:

1. Hover over the green circle -> Properties are shown on the right side of the map (using the queryRenderedFeatures API)

2. Zoom further in

3. Hover again over the green circle -> Properties are NOT shown on the right side of the map

Please note:
Sometimes it is necessary to repeat steps 2 and 3 to reproduce.
Zoom extend of the used vector tileset for the point: z11-z12

Edit:
Is a z12 tile at zoom 12.1 overzoomed or not?

[anandthakker]

@mike-marcacci Thanks for reporting and for the screencast. Is there any chance you'd be able to share a live page that reproduces the issue? So far, I haven't managed to reproduce it locally.
(@pathmapper's jsfiddle above does reliably show an issue [thanks!], but it's not clear that it's the same as the one you're seeing)

[mike-marcacci]

Hi @anandthakker, thanks for the reply. I don't have anything live running this version (I'm just running the previous one instead), but I'll try to get a simplified working demo live today.

[anandthakker]

I believe the overzooming problem that @pathmapper described above happens like so:

• [render frame 1] Map starts at z12, so initial symbol placement occurs using tile 12/1283/1587.

• Zoom to z13; this means that we have a new, overzoomed version of the above tile (13/1283/1587 in the debug view)

• [render frame 2] We start a new placement, but it gets paused. Thus this code updating map.style.collisionIndex doesn't run:

  mapbox-gl-js/src/style/style.js

  Lines 991 to 999 in de593c8

  	if (this.pauseablePlacement.isDone()) {
  	const placement = this.pauseablePlacement.placement;
  	placementChanged = placement.commit(this.placement, browser.now());
  	if (!this.placement || placementChanged || symbolBucketsChanged) {
  	this.placement = placement;
  	this.collisionIndex = this.placement.collisionIndex;
  	}
  	this.placement.setRecent(browser.now(), placement.stale);
  	}

• (btw, there might be some other issue at play here: it's not clear why we'd ever have to pause placement when we're only placing a single symbol, as in this example)

• [render frame 3] We continue the paused placement, and complete it. However, since the crossTileSymbolIndex got updated in the previous frame, symbolBucketsChanged is false this time. And (I think?) because we're placing the same symbol again this time, placementChanged also comes back false. As a result, we still don't update map.style.collisionIndex.

The consequence: even though map.style.sourceCache is now operating off of the overzoomed (13/1283/1587) tile, the feature entry in map.style.collisionIndex refers to the original (12/1283/1587) tile, and thus gets filtered out of the query results.

cc @ansis @ChrisLoer

[anandthakker]

@mike-marcacci I'd be curios to know if this branch still exhibits the problem for you: #6104

[mike-marcacci]

Hey there, so sorry for the delay; I haven’t had any cell service here and am just trying to get this out on 1 bar 😑. I will try with that branch as soon as I can download it!! Thanks so much for the super fast response here.

…

Sent from my iPhone

On Feb 6, 2018, at 21:36, Anand Thakker ***@***.***> wrote: @mike-marcacci I'd be curios to know if this branch still exhibits the problem for you: #6104 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[mike-marcacci]

Hey team, sorry again for the delay – finally back on the grid. I can confirm that the branch 6074 (from PR #6104) restores the behavior from 0.43.0! Thanks for the quick fix!

[anandthakker]

Thanks for confirming, @mike-marcacci

[anandthakker]

Fixed in #6104

[gmaclennan]

@anandthakker I am still seeing this bug in 0.44.1 - just realized that the map we built for our partners is not working just before they have a major launch this week! Returning to 0.43.0 works. Live example here: https://wherewework.amazonfrontlines.org/ source code: https://github.com/digidem/alianza-ceibo-maps/

[anandthakker]

Thanks @gmaclennan. I suspect this might be a different underlying issue, but it's hard to be sure without a minimal reproduction -- could you either describe the details of the querying that's happening in your example or reduce it to a smaller example free of extraneous application code?

[gmaclennan]

Hey @anandthakker thanks for the quick response. This looks like it was a weird caching issue both on the published version and on my local dev machine, which means that the update to 0.44.1 was not coming through correctly. Anyhow, it seems to have started working again now.