Is your feature request related to a problem?
When you click "Try it out" on an operation with multiple response content types, the "Response content type" dropdown currently appears after the "Execute" button in the rendered layout. I'm always frustrated when I click Execute out of habit and only afterward notice the content type dropdown below it, meaning the request may have gone out with the wrong Accept header value.
Describe the solution you'd like
Reorder the operation panel so the "Response content type" dropdown is rendered above (before) the "Execute" button, grouped together with the
other request-configuration controls (parameters, request body, parameter content type, etc.) that already appear before Execute. This way all
inputs that affect the outgoing request are visually grouped together, followed by the action button.
Describe alternatives you've considered
- Keeping the current order but adding a scroll/visual cue directing users back up to the dropdown after clicking "Try it out".
- Making the dropdown's position configurable via a layout/plugin option for consumers who prefer the current order.
Additional context
- Swagger-UI version: swagger-ui-react ^5.9.1
- Method of installation: npm, used as a React component (create-react-app / react-scripts) inside a Java Quarkus backend project, built via Maven's frontend-maven-plugin
- Browser: Chrome
- Swagger/OpenAPI spec version: OpenAPI 3.0.1 (see minimal example above)
Is your feature request related to a problem?
When you click "Try it out" on an operation with multiple response content types, the "Response content type" dropdown currently appears after the "Execute" button in the rendered layout. I'm always frustrated when I click Execute out of habit and only afterward notice the content type dropdown below it, meaning the request may have gone out with the wrong
Acceptheader value.Describe the solution you'd like
Reorder the operation panel so the "Response content type" dropdown is rendered above (before) the "Execute" button, grouped together with the
other request-configuration controls (parameters, request body, parameter content type, etc.) that already appear before Execute. This way all
inputs that affect the outgoing request are visually grouped together, followed by the action button.
Describe alternatives you've considered
Additional context