manojshetty2004 commented on issue #37858: URL: https://github.com/apache/superset/issues/37858#issuecomment-5374085530
@rusackas @uvv-01 Investigated this on current master. Summary below — attaching screenshots. Setup: Local dev environment, superset-frontend running via npm run dev-server Dashboard with native filters, switched to filter_bar_orientation: HORIZONTAL via the filter bar's own orientation setting Tested with 6 filters added (filter 2 through filter 6, mixed column types) Testing overlap at reduced widths: Using Chrome DevTools responsive mode, tested at 1366px and 1024px (both called out in the issue description). At both widths, I could not reproduce the overlap. Instead of wrapping onto a second line, the filter bar correctly collapses overflow filters into a "More filters" dropdown button, and the chart grid below renders with no overlap at all. Screenshots attached: [1366px](https://github.com/apache/superset/issues/37858#) / [1024px](https://github.com/apache/superset/issues/37858#). This suggests the overflow-handling logic already in FilterBar/FilterControls/FilterControls.tsx (the DropdownContainer component) is correctly preventing the wrap-and-overlap behavior described here, at least for this scenario. Separate observation — filter count limit: While trying to add more filters to stress-test this further (8-10+, per "when multiple native filters are added" in the description), I ran into a UI issue: adding a 6th+ filter via the filter config modal appears to replace an existing filter instead of adding a new one. I wasn't able to get past 5-6 simultaneous filters as a result, which limited how far I could push this test. This might be worth its own issue if it's not already tracked — it's blocking proper stress-testing of the overlap bug here. Can look into filing that separately unless someone flags it as a known/expected limitation. Next steps I'm considering: Testing at narrower/tablet widths (768px, 600px) Checking if the "More filters" popover itself has any positioning/clipping issues Testing with a required filter (empty/error state) in case a taller filter chip is the actual trigger Happy to keep digging, but wanted to post this checkpoint in case the overlap bug is already resolved on master and this issue can be narrowed or closed, pending maintainer input. A few notes before you post: Attach both screenshots where I marked [1366px](#) / [1024px](#) — GitHub will auto-generate the links once you drag the images into the comment box. I'd hold off on saying "there is no error" as a flat conclusion — the draft above frames it as "couldn't reproduce under this specific test," which is more accurate and less likely to get pushback from maintainers who might know of edge cases you haven't hit yet. The filter-replacement bug is worth flagging but shouldn't be buried in the same paragraph as your overlap findings — I split it out so it reads as a distinct, separate observation. Want me to adjust the tone, shorten it, or fold in the 768px/more-filters testing once you've done it? <img width="1345" height="752" alt="Image" src="https://github.com/user-attachments/assets/fccb78b8-577b-4cbc-b95f-7ec9178d5768"; /> <img width="1349" height="734" alt="Image" src="https://github.com/user-attachments/assets/69dff4b4-cc9e-4e75-a2f1-70ad11790fe4"; /> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
