Query parameter of type array with object $ref items renders as JSON editor instead of dynamic form rows

[jgarciadelanoceda]

Q&A (please complete the following information)

• OS: [Windows]
• Browser: [Chrome]
• Swagger-UI version: [5.32.8]
• Swagger/OpenAPI version: [3.0]

Description

When an OpenAPI 3.0 operation defines a query parameter with style: form, explode: true, and a schema of type: array whose items is a $ref to an object schema, Swagger UI renders the parameter as a single JSON text editor instead of a dynamic list of form rows with individual fields per object property.

Example Swagger/OpenAPI definition:

{
            "name": "Custom",
            "in": "query",
            "schema": {
              "type": "array",
              "items": {
                "$ref": "#/components/schemas/Presentation.Dtos.Customers.Requests.CustomQuery"
              },
              "nullable": true
            }
          }
"Presentation.Dtos.Customers.Requests.CustomQuery": {
        "type": "object",
        "properties": {
          "id": {
            "type": "integer",
            "format": "int32"
          },
          "value": {
            "type": "string",
            "nullable": true
          }
        },
        "additionalProperties": false
      }

Describe the bug you're encountering

The parameter renders as a JSON textarea. The user must type raw JSON to interact with it at all. The submitted request does not use bracket notation, making the parameter unusable against servers that expect it.

Expected behavior

Swagger UI should render an "Add item" button that, for each added item, expands the object properties as individual labelled input fields — consistent with how it handles array of primitives (string/integer) today, but applied recursively to object properties.
The resulting query string sent by Swagger UI should follow the indexed bracket notation that most server frameworks (e.g. ASP.NET Core, Express with qs) expect:
?Custom[0].Id=1&Custom[0].Value=foo&Custom[1].Id=2&Custom[1].Value=bar

Screenshots

Additional context or thoughts

It could be related to #2707