Repository navigation
"Drill to detail by" doesn't let you pick which "by" you want (6.0.0rc2) #35495
Description
Bug description
In 4.1.3 I can choose a specific aspect to drill by - here I'm hovering over "Trash", see how that's greyed-out:
In 6.0.0rc2 when I mouse over one, they all highlight and get clicked as one:
Screenshots/recordings
No response
Superset version
master / latest-dev
Python version
I don't know
Node version
I don't know
Browser
Firefox
Additional context
No response
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.
Activity
dosubot commentedon Oct 3, 2025
This looks like a regression introduced by recent frontend refactoring in Superset. The switch from Ant Design's Menu component (with openKeys state management) to Dropdown's menu prop and custom submenu components (like DrillBySubmenu) changed how drill menu items are rendered and interacted with. As a result, all "Drill to detail by" options may highlight and get clicked as one, instead of allowing selection of a specific aspect. This is likely due to submenu open state or event handling not being managed correctly after the refactor (PR #35122, PR #34424).
No existing tickets or docs cover this specific regression, and none of the recent PRs explicitly fix it. If you need a workaround, you might try using a different browser or reverting to an earlier version, but the underlying issue is in the frontend code and will likely need a fix in a future release. Monitoring the ChartContextMenu and DrillBySubmenu components for updates is recommended.
To reply, just mention @dosu.
Docs are dead. Just use Dosu.
LevisNgigi commentedon Oct 6, 2025
I am on master branch and could not reproduce this,works fine there.
sadpandajoe commentedon Oct 7, 2025
@LevisNgigi do you know which pr might have fixed this?
sadpandajoe commentedon Oct 7, 2025
@sfirke this might be fixed as part of rc3, i'll leave this open for now
LevisNgigi commentedon Oct 7, 2025
@sadpandajoe Finding the exact pr would need further investigation because in 6.0.0rc2 issue exists but in current master branch the issue seems to be solved.
sfirke commentedon Oct 7, 2025
@sadpandajoe is there a way for me to build the in-progress 6.0 branch, so I could test if that's the case? I'm thinking I can check out that v6.0 tag in git and build from there, and it would reflect whatever you have cherried thus far.
sadpandajoe commentedon Oct 7, 2025
@sfirke two ways, you can either check out the
6.0branch directly and build it or you can go to the PR i have for it, bring down the testenv and bring up a new one.sadpandajoe commentedon Oct 17, 2025
Spun up an ephemeral with latest code that will be in RC3. Going to mark this as closed as we probably cherried the fix at some point
sfirke commentedon Nov 24, 2025
I just confirmed this is fixed in 6.0.0rc3 ✔️