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
- [x] I have searched Superset docs and Slack and didn't find a solution to my problem.
- [x] 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.
Comment From: dosubot[bot]
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.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other 
Comment From: LevisNgigi
I am on master branch and could not reproduce this,works fine there.
Comment From: sadpandajoe
@LevisNgigi do you know which pr might have fixed this?
Comment From: sadpandajoe
@sfirke this might be fixed as part of rc3, i'll leave this open for now
Comment From: LevisNgigi
@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.
Comment From: sfirke
@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.
Comment From: sadpandajoe
@sfirke two ways, you can either check out the 6.0 branch 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.