zmuxuny opened a new issue, #6063: URL: https://github.com/apache/rocketmq-dashboard/issues/6063
### Before Creating the Bug Report - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) of this repository and believe that this is not a duplicate. - [x] This is a defect in RocketMQ Studio, not a usage question and not a defect in another Apache RocketMQ repository. - [x] I can reproduce this on the current `master` branch, or I have stated the exact version I am running below. ### Studio Version Source inspected at rocketmq-studio@7360f3e2b921604c9bfe5163d89da51dfde3bf7d. This is source inspection plus maintainer review, not a new all-pages visual verification. ### Runtime Environment Studio web frontend. Remaining fixed-width page controls identified in source; real-browser viewport validation is required as detailed below. ### Connected RocketMQ Cluster No cluster needed for this source-level report. Future browser verification should use controlled populated/empty/error fixtures. ### Build Toolchain _No response_ ### Describe the Bug ### Scope Follow-up to the page-level concerns in [PR #5025 review 5477880966](https://github.com/apache/rocketmq-dashboard/pull/5025#pullrequestreview-5477880966). #5025 is being narrowed to MainLayout navigation/header only. This tracks the separate page-controls work and does not claim the shell fix makes every page responsive. ### Current behavior and source evidence On `rocketmq-studio@7360f3e2b921604c9bfe5163d89da51dfde3bf7d`, fixed-width controls remain in: - `web/src/pages/cluster/index.tsx` (240px filter controls) - `web/src/pages/cluster/clients.tsx` (240px control) - `web/src/pages/instance/index.tsx` (240px control) - `web/src/pages/instance/acl.tsx` (240/260px controls) - `web/src/pages/instance/message.tsx` (300/260px selectors and 240/400px query fields) The maintainer also identified `cluster/certs.tsx`, `instance/consumer.tsx`, and `instance/dlq.tsx` for the same responsive audit. Some numeric widths are table-column sizing rather than form controls; the follow-up should distinguish these instead of blindly replacing all fixed widths. ### Expected behavior / proposed discussion Agree a shared page-level strategy (wrapper component or utility class) so filters and query controls can wrap or scroll within narrow content areas without losing controls or changing intended desktop widths. Cover all identified pages together, including the remaining selectors in message.tsx. PR #5025 uses complementary 767px CSS / 768px matchMedia thresholds only for MainLayout's sidebar/header transition. It does not establish an app-wide breakpoint convention. If maintainers choose to adopt a project-wide breakpoint, document that decision in conventions.md as part of this follow-up. ### Validation required Use a real browser at 320, 375, 767, 768, 1280 and 1440px. Exercise every listed page, populated/empty/error states, filter selection, drawers/modals and resize transitions; distinguish intended table scrolling from unintended page/control clipping. jsdom state-machine tests alone do not validate CSS media queries. Source inspection confirms the remaining widths. No new all-pages visual verification is claimed by this issue. ### Steps to Reproduce Inspect the fixed-width controls in the listed cluster and instance pages. For a concrete visual audit, exercise each at 320, 375, 767, 768, 1280 and 1440px, including filter selection, drawers/modals and resize transitions. Distinguish intended table scrolling from control clipping. This issue does not claim that matrix has already been run. ### What Did You Expect to See? Agree a shared page-level strategy so filters and query controls wrap or scroll within narrow content areas without losing controls or changing intended desktop widths. Keep this separate from the MainLayout-only fix in #5025. ### What Did You See Instead? Source retains 240px/260px/300px/400px form-control widths across the named pages, and the maintainer requested a broader responsive audit. PR #5025's shell change does not make those pages fully responsive. ### Additional Context Follow-up to https://github.com/apache/rocketmq-dashboard/pull/5025#pullrequestreview-5477880966. The 767px CSS / 768px matchMedia pairing in #5025 is a shell-local threshold, not an established app-wide breakpoint convention. ### Are You Willing to Submit a Pull Request? - [ ] Yes, I am willing to submit a pull request. -- 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]
