zmuxuny opened a new issue, #6358: URL: https://github.com/apache/rocketmq-dashboard/issues/6358
### 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 - Branch: `rocketmq-studio` - Commit: `779b8c0e7aed2396d3cc72743dcd544ea48e9ae6` - Verified against a source checkout with frontend component/unit tests. ### Runtime Environment Linux, Node.js 24.19.0, the repository's installed Vitest/jsdom stack. All API calls in the reproduction are mocked. This report does not claim a live-browser or live-cluster reproduction. ### Connected RocketMQ Cluster Not required. The defect is in frontend query state and reproduces with ordinary successful metrics responses. ### Build Toolchain _No response_ ### Describe the Bug The custom PromQL textarea treats every unshifted Enter as Run, including the Enter used to confirm an input-method candidate. This unexpectedly executes the expression while the user is still editing a non-ASCII Prometheus label value and may replace the current result with a partial-expression error or an unintended query result. Prometheus label values can contain non-ASCII text, for example `environment="生产"`. The problem is not limited to RocketMQ resource identifiers. ### Steps to Reproduce 1. Open Metrics Explorer and enter a custom expression containing a non-ASCII label value, such as `sum(rocketmq_messages_in_total{environment="生产"})`. 2. While using a Chinese/Japanese/Korean input method to edit the label value, press Enter to confirm the candidate. 3. Observe that the query runs before a separate submit action. The component regression changes the textarea value, dispatches compositionstart, then dispatches Enter with `isComposing: true`. The query mock is called immediately. ### What Did You Expect to See? IME confirmation should remain an editing action. It must neither submit the query nor prevent the input method's default handling. A later ordinary Enter should run it, and Shift+Enter should remain a newline. ### What Did You See Instead? `web/src/components/MetricsExplorer.tsx:1483-1486` checks only `!event.shiftKey`, then calls `preventDefault()` and `runCustomQuery`. The red regression expects the existing query-call count to stay at one during composition, but it becomes two. ### Additional Context The shared AI Composer already applies the repository's intended keyboard behavior: `event.nativeEvent.isComposing || event.nativeEvent.keyCode === 229` returns early (`web/src/pages/ai/components/Composer.tsx:269-272`). MetricsExplorer's `Input.TextArea` lacks this guard, and the installed rc-textarea does not supply one before calling onPressEnter. Regression coverage should exercise native isComposing, the WebKit keyCode-229 fallback, normal Enter, Shift+Enter, and the Run button. No query protocol or backend changes are needed. Verified red on unchanged production: the real-component test fails on the extra API query while composition is active. No production fix, browser input-device test, or full-suite pass is claimed yet. AI assistance was used for investigation and test preparation. ### Are You Willing to Submit a Pull Request? - [x] 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]
