Deck.gl GeoJson Polygon Plot Tooltip does not include aggregation metric

[pSpitzner]

Since PR #34276 we have the ability to adjust the tooltip of a deck.gl GeoJson Polygon charts through a unified interface:

• a) how to determine each polygons color, via the Metric selector (avialable before the PR)
• b) which metrics to include, via the list of Tooltip contents
• c) how to style them, via the Customize tooltips template

However, achieving a simple tooltip that shows an aggregated metric (say computed_metric) along with some corresponding meta data (say time and location) is currently not possible.

Desired outcome

*CSP needs to be disabled

Isolation

• To use custom sytling (c), CSP has to be disabed or adjusted (e.g. TALISMAN_ENABLED = False).
• Without anything added to (b), the default template includes the computed_metric.
• When adding meta data by including them in (b), the default style does not include the computed_metric. This does not require adjusting CSP.
• The ui does not permit adding computed_metric in (b): Only real data columns can be selected, no custom sql and no predefined dataset-level metrics.

Conclusion

• In combination, it is currently not possible, to get tooltip with a custom metric and metadata, without disabeling CSP.

Proposed solution

• The default template that is used when columns are added into (b) should include the defined Metric (a)
• The UI should inform the user that (c) does not use handlebars (but a javascript render), which requires disableing CSP.

Screenshots

default template without columns added to (b)

---

default template with columns added to (b)

---

no computed metrics can be selected in (b)

Additional context

Tested in Superset v6.1.0

Related Issues and PRs

• feat(custom-tooltip): custom tooltip on deck.gl charts #34276 (introduces new tooltip ui)
• refactor(deckgl): update deck.gl charts to use new api #34859 (not effective here yet afaik)
• feat: use in deck.gl custom tooltip instead of SafeMarkdown #35665 (html sanitization for tooltip ui)
• fix(explore): Remove query autotrigger #35418 (small fix for auto-triggering rerender)

Insights from Dosu:

• (c) is processed as JavaScript using a sandboxed vm.runInNewContext() execution environment [1]. Internally, this calls sandboxedEval() which uses dynamic code evaluation — and that's exactly what triggers the CSP 'unsafe-eval' violation you're seeing [2].

Checklist

• I have searched Superset docs and Slack and didn't find a solution to my problem.
• I have searched the GitHub issue tracker and didn't find a similar bug report.
• I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

[dosubot]

Hi @pSpitzner! I'm Dosu and I'm helping the Apache Superset team.

Your analysis is spot on. I looked into the code and can confirm the root cause: there's a fundamental disconnect between the frontend tooltip system (introduced in PR #34276) and the backend data population logic.

The issue in detail:

The backend populates tooltip data via extraProps, which is driven by the js_columns form setting [1]. When you add columns to "Tooltip contents," the frontend expects those fields to exist in the picked object, but there's no logic connecting tooltip_contents to the extraProps population on the backend side — they are independent settings. The computed metric isn't automatically included in extraProps when additional columns are specified.

Possible workarounds (none fully satisfying without CSP changes):

1. Custom js_tooltip JavaScript — the js_tooltip form control [2] lets you override the default tooltip rendering entirely [3], but this runs arbitrary JS so it has the same CSP issue you noted.
2. Custom Handlebars template — if the computed metric is present in the object data, you can reference it in a template, but as you noted this also requires CSP adjustments.

For a proper fix, I agree with your proposed solution: the default template used when columns are added to "Tooltip contents" should automatically include the Metric field. On the backend side, this would mean ensuring the computed metric is included in the data made available to the tooltip (either by adding it to extraProps or by having the frontend tooltip builder pull it from the object's top-level properties where it's already available for coloring).

One additional note: the entire deck.gl visualization class hierarchy is marked as deprecated since version 3.0 [4], so any fix here would be patching legacy code. That said, until it's replaced, this is a valid usability gap worth addressing.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[rusackas]

Tempted to convert this to an "Ideas" discussion, if it's not quite a Superset bug, but if you want to open a PR, that'd be awesome (or maybe @DamianPendrak or @geido haive ideas/bandwidth here). Any help/contribution appreciated.