After we upgraded to 3.0.0, we have received user reporting query results not rendering in sqllab results. I have checked the api call results in network tab and can confirm the correct value has been returned from the backend database. So this seems like an issue with front end.
How to reproduce the bug
- Go to Sqllab, select any database (I tested this on Presto and MySQL)
- Run
SELECT '<abcdef:12345>' as test_str - Run the query
- See error
Expected results
String values rendered as in 2.0.0
Actual results
String values not being rendered
Screenshots
If applicable, add screenshots to help explain your problem.
Environment
(please complete the following information):
- browser type and version: Chrome latest stable version
- superset version:
superset version3.0.0 - python version:
python --version3.9 - node.js version:
node -vv20.8.0 - any feature flags active: N/A
Checklist
Make sure to follow these steps before submitting your issue - thank you!
- [x] I have checked the superset logs for python stacktraces and included it here as text if there are any.
- [x] I have reproduced the issue with at least the latest released version of superset.
- [x] I have checked the issue tracker for the same issue and I haven't found one similar.
Additional context
Add any other context about the problem here.
Comment From: zhaorui2022
I have taken a look at the code but don't have a clue due to lack of front end code knowledge. @justinpark Do you happen to know what the problem might be?
Comment From: bkyryliuk
probably related code: https://github.com/apache/superset/blob/178607093fa826947d9130386705a2e3ed3d9a88/superset-frontend/packages/superset-ui-core/src/utils/html.tsx#L35
See: https://github.com/apache/superset/blob/178607093fa826947d9130386705a2e3ed3d9a88/superset-frontend/packages/superset-ui-core/src/utils/html.tsx#L31 Effectively it removes all it thinks is html.
Comment From: rusackas
This is still happening on current master. We're open to proposals/PRs to fix this.
Comment From: rusackas
Noting that in the chart builder, unchecking HTML rendering doesn't fix the issue there either.
Comment From: rusackas
I know @mistercrunch has looked at some of this HTML rendering business, just in case he sees any obvious solution here
Comment From: mistercrunch
Recent related feature -> https://github.com/apache/superset/pull/27969, so it looks like it can be switched off, but given the issue here, better/smarter html detection could help as well. For SQL Lab specifically looks like the flag lives there superset-frontend/src/utils/localStorageHelpers.ts, but idk how these flags get set/managed (?)
Comment From: mistercrunch
For the record I think this is the area that would need to be improved if we wanted to be smarter around detecting html -> https://github.com/apache/superset/blob/master/superset-frontend/packages/superset-ui-core/src/utils/html.tsx#L43-L45
Comment From: rusackas
Still happening in 4.1.2, but this has been silent for upward of 6 months, and is likely to be closed as "not planned" before long, unless anyone here on the thread wants to tackle it. PRs welcome!
Comment From: rusackas
Maybe @dosu-bot can help move this forward.
Comment From: rusackas
I meant, maybe @dosu can help.
Comment From: dosubot[bot]
The root cause is the frontend’s aggressive HTML detection logic: any string with angle brackets (like <abcdef:12345>) is classified as HTML by the isProbablyHTML function, even if it’s not valid HTML. When this happens, Superset tries to render it as HTML using dangerouslySetInnerHTML, but browsers ignore unknown tags, so nothing appears in the cell. This is why toggling the “Render HTML” option doesn’t fix the issue—the detection logic still treats these strings as HTML and hides them, regardless of the toggle’s state. The relevant code is in superset-frontend/packages/superset-ui-core/src/utils/html.tsx and is global and hardcoded, so there’s no user-facing way to adjust this behavior without a code change. See this related issue and explanation.
Workarounds include disabling HTML rendering for affected columns (where possible) or preprocessing your data to escape angle brackets (replace < with < and > with >). To truly fix this, the detection logic in isProbablyHTML would need to be refined to better distinguish between actual HTML and plain strings with angle brackets. No recent PRs address this yet.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other 
Comment From: rusackas
Opened a PR ^^