fix: fixed navigation to the relevant input field#4026
Conversation
JamalAlabdullah
added
kind/bug
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughExports new function Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning Review ran into problems🔥 ProblemsTimed out fetching pipeline failures after 30000ms Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
JamalAlabdullah
added
the
squad/utforming
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
src/layout/GenericComponent.tsx (1)
274-289: Consider filtering non-interactive candidates before fallback focus.If fallback selects a disabled/hidden/inert element, focus can silently fail even though a valid input exists later in the list.
Suggested hardening
const targetElements = Array.from( div.querySelectorAll<HTMLElement>( ['input', 'textarea', 'select', 'button', '[tabindex]:not([tabindex="-1"])', '[contenteditable="true"]'].join( ',', ), ), - ); + ).filter( + (element) => + !element.matches(':disabled, [hidden], [aria-hidden="true"], [inert], input[type="hidden"]'), + );🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/layout/GenericComponent.tsx` around lines 274 - 289, The current focus fallback can pick non-interactive elements; update the selection to filter out disabled/hidden/inert/non-visible candidates before choosing a fallback: after building targetElements (from querySelectorAll), run a filter that removes elements with hidden attribute, aria-hidden="true", inert attribute, style.display === 'none' or style.visibility === 'hidden' or getClientRects().length === 0 (or offsetParent === null for robustness), and for form controls check the disabled property; keep the binding lookup (elementWithBinding) using the same dataset.bindingkey check but apply the same filter so the returned element (elementWithBinding ?? first) is guaranteed interactive. Ensure you still return undefined when no interactive candidates remain.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@src/layout/GenericComponent.tsx`:
- Around line 274-289: The current focus fallback can pick non-interactive
elements; update the selection to filter out disabled/hidden/inert/non-visible
candidates before choosing a fallback: after building targetElements (from
querySelectorAll), run a filter that removes elements with hidden attribute,
aria-hidden="true", inert attribute, style.display === 'none' or
style.visibility === 'hidden' or getClientRects().length === 0 (or offsetParent
=== null for robustness), and for form controls check the disabled property;
keep the binding lookup (elementWithBinding) using the same dataset.bindingkey
check but apply the same filter so the returned element (elementWithBinding ??
first) is guaranteed interactive. Ensure you still return undefined when no
interactive candidates remain.
…eilmedlingslink-feiler-for-inputfelt-med-markdown-lister
There was a problem hiding this comment.
🧹 Nitpick comments (1)
src/layout/GenericComponent.test.tsx (1)
78-136: Add one regression test for the real error-link flow (markdown list + intro text).These helper tests are strong, but they don’t directly cover the bug’s full path (clicking error message link and focusing the target input when description has leading text + markdown list). Please add one component-level regression test for that interaction.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/layout/GenericComponent.test.tsx` around lines 78 - 136, Add a component-level regression test that renders GenericComponent (or the component that uses findElementToFocus) with an error message containing leading intro text plus a markdown list (e.g., "Intro text\n\n- item") and an error link that targets a field by data-bindingkey; use the existing test helpers (createContainer or test renderer) to render the DOM, simulate a user click on the error link (fireEvent.click or userEvent.click), then assert that the input/textarea with the matching data-bindingkey receives focus (expect(document.activeElement).toBe(targetElement) or expect(targetElement).toHaveFocus()). Ensure the test exercises the same code path as findElementToFocus so it verifies focusing works when the description contains both intro text and a markdown list.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@src/layout/GenericComponent.test.tsx`:
- Around line 78-136: Add a component-level regression test that renders
GenericComponent (or the component that uses findElementToFocus) with an error
message containing leading intro text plus a markdown list (e.g., "Intro
text\n\n- item") and an error link that targets a field by data-bindingkey; use
the existing test helpers (createContainer or test renderer) to render the DOM,
simulate a user click on the error link (fireEvent.click or userEvent.click),
then assert that the input/textarea with the matching data-bindingkey receives
focus (expect(document.activeElement).toBe(targetElement) or
expect(targetElement).toHaveFocus()). Ensure the test exercises the same code
path as findElementToFocus so it verifies focusing works when the description
contains both intro text and a markdown list.
ℹ️ Review info
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/layout/GenericComponent.test.tsxsrc/layout/GenericComponent.tsx
🚧 Files skipped from review as they are similar to previous changes (1)
- src/layout/GenericComponent.tsx
…eilmedlingslink-feiler-for-inputfelt-med-markdown-lister
|
walldenfilippa
left a comment
walldenfilippa
left a comment
There was a problem hiding this comment.
Nice job! I left a minor nitpick :)
|
JamalAlabdullah
deleted the
3967-navigasjon-via-feilmedlingslink-feiler-for-inputfelt-med-markdown-lister
branch
github-project-automation
bot
moved this from 🔎 In review
to ✅ Done
in Team Altinn Studio
* fix: fixed navigation to the relevant input field * refactor * refactor * added tests * refactor
|
✅ Automatic backport successful! A backport PR has been automatically created for the The release branch The cherry-pick was clean with no conflicts. Please review the backport PR when it appears. |
2 participants
Description
Related Issue(s)
Screen.Recording.2026-02-27.at.12.40.44.mov
Verification/QA
kind/*andbackport*label to this PR for proper release notes groupingSummary by CodeRabbit