Skip to content

fix(workflow-form): the read-only input card blocks the pointer but not the keyboard #8943

Closed

Description

@yangzhang75

What happened?

The Form View's read-only input card locks itself with pointer-events: none (workflow-form.component.scss:340, applied by [class.read-only]="!canEdit" at workflow-form.component.html:232). That only blocks pointing-device hit testing. A keyboard user can Tab into a custom widget's own controls inside the card -- a file picker's Browse button, the HuggingFace file input -- and activate them with Enter or Space. The bound formly controls are disabled through props.disabled, but the controls a widget draws of its own do not consult the form's disabled state: the HuggingFace audio input, for one, POSTs the selected file.

Expected: read-only blocks keyboard interaction as well as pointer. The step panel already does this with inert for the same reason (workflow-form.component.html:484, [attr.inert]="panelLive ? null : ''"); the input card should follow.

Part of #8439 (item 5) and the Form View feature #8011. Raised by Copilot on #8437, #8438 and #8440.

How to reproduce?

  1. Open a workflow that exposes a HuggingFace audio (file) input in the Form View, as a user without write access (the card is read-only).
  2. Press Tab until the focus lands on the widget's file input or Browse button inside the card.
  3. Press Enter or Space and choose a file.
  4. The upload request goes out although the card is read-only.

Fix sketch: put inert on the read-only card, giving the container tabindex="-1" and an aria-label so keyboard users can still scroll it (the step panel's precedent), or disable every descendant control semantically. A DOM test that focuses a widget control inside a read-only card and asserts it can be neither focused nor activated.

Version/Branch

1.4.0-incubating-SNAPSHOT (main)

Commit Hash (Optional)

506397a

What browsers are you seeing the problem on?

Chrome

Relevant log output

No response


Re-filed from #8758, which was taken by another contributor while the fix was already queued behind the open PRs in this series; closing and re-filing keeps the claim and the work in one place.

Activity

  1. yangzhang75 commented on Oct 9, 2026

    @yangzhang75
    ContributorAuthor

    /take

  2. added theissue type on Oct 9, 2026
  3. added a commit that references this issue on Oct 19, 2026
    a46ddc6
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions