fix: avoid error validate nested DOM

[urmauur]

Describe Your Changes

Fixes Issues

Make sure the issue not show on console

• Closes #
• Closes #

Self Checklist

• Added relevant comments, esp in complex areas
• Updated docs (for bug fixes / features)
• Created issues for follow-up changes or refactoring needed

---

Important

Replace button elements with div elements having role="button" and tabIndex=0 to improve accessibility and prevent nested DOM errors in dialog components.

• Accessibility Improvements:
  • Replace button with div having role="button" and tabIndex=0 in DeleteMessageDialog.tsx, EditMessageDialog.tsx, and MessageMetadataDialog.tsx.
  • Add onKeyDown handlers to handle Enter and Space keys for opening dialogs.
• Error Handling:
  • Ensure error details can be expanded/collapsed with keyboard in ErrorDialog.tsx and LoadModelErrorDialog.tsx.
  • Add onKeyDown handlers for Enter and Space keys to toggle error details.

^{This description was created by for 4293fe7. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed everything up to 4293fe7 in 2 minutes and 20 seconds. Click for details.

• Reviewed 142 lines of code in 5 files
• Skipped 0 files when reviewing.
• Skipped posting 3 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. web-app/src/containers/dialogs/DeleteMessageDialog.tsx:44

• Draft comment:
  The interactive div replacing the button only has an onKeyDown handler. Ensure that mouse click events are also handled (either via an explicit onClick or by confirming that DialogTrigger injects the click behavior) so that pointer users aren’t affected.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The comment raises a valid accessibility concern about the div's click handling. However, the div is wrapped in DialogTrigger which likely handles click events automatically. UI component libraries typically handle this. Without seeing the DialogTrigger implementation though, I can't be 100% certain. I'm making assumptions about DialogTrigger's behavior without seeing its implementation. The comment author may have knowledge about DialogTrigger that I don't. While true, UI component libraries almost universally handle click events on their trigger elements. The presence of DialogTrigger and the fact this is a UI component strongly suggests click handling is covered. Given the presence of DialogTrigger and that this is clearly a UI component, we should err on the side of assuming click handling is properly implemented by the component library.

2. web-app/src/containers/dialogs/EditMessageDialog.tsx:67

• Draft comment:
  This div used as a trigger has an onKeyDown handler for Enter and Space but no onClick. Verify that mouse clicks trigger the dialog (either via DialogTrigger or by adding an onClick) to maintain full interactivity.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

3. web-app/src/containers/dialogs/DeleteMessageDialog.tsx:48

• Draft comment:
  The inline onKeyDown logic (checking for 'Enter' or space) is repeated across multiple dialogs. Consider extracting this handler into a shared function or component to reduce duplication and improve maintainability.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% While the comment identifies potential duplication, I don't have evidence that this exact pattern is repeated "across multiple dialogs" as claimed. The two handlers in this file serve different purposes (open vs confirm). Without seeing other dialog files, I can't verify if this pattern truly needs extraction. The current inline implementation is clear and simple. I could be undervaluing the benefit of consistency in keyboard handling across the app. Maybe there are many other dialogs with similar patterns. Without concrete evidence of duplication across files, suggesting extraction could lead to premature abstraction. The current implementation is straightforward and localized. Delete the comment since we lack evidence of widespread duplication that would justify extraction, and the current implementation is clear and maintainable.

Workflow ID: wflow_h5EDnyBiW6wuOGfV

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[github-actions]

Barecheck - Code coverage report

Total: 29.38%

Your code coverage diff: -0.05% ▾

Uncovered files and lines

File	Lines
web-app/src/containers/dialogs/DeleteMessageDialog.tsx	26-28, 30-33, 35-39, 41-53, 55-61, 64-71, 73-75, 78-92, 94-99, 101
web-app/src/containers/dialogs/EditMessageDialog.tsx	28-35, 37-39, 41-48, 50-55, 57-62, 64-76, 78-84, 87-112, 114-119, 121
web-app/src/containers/dialogs/ErrorDialog.tsx	1, 9-15, 17-21, 23-39, 41-43, 45-60, 62-74, 76-77, 79-80, 82, 84-91, 93-94, 96-98, 100-104, 106-113, 115-119, 121-124, 126-129, 131
web-app/src/containers/dialogs/LoadModelErrorDialog.tsx	1, 9-15, 17-21, 23-29, 31-33, 35-36, 38, 40-41, 46-53, 55-56, 62-63, 65-66, 68-84, 86-88, 90-100, 102-105, 107-118, 120-125, 127-129, 132-144, 146-147, 149-150, 152, 154-161, 163-164, 166, 168, 170-174, 176-183, 185-189, 191-194, 196-199, 201
web-app/src/containers/dialogs/MessageMetadataDialog.tsx	26-30, 32-44, 46-52, 55-79, 81