cps-dialog: focus ring on the dialog frame covers the dialog and blocks all clicks inside it
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 72/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- angular, css, playwright, scss, typescript
- Domain
- frontend
Research direction
Start with the focus-ring mixin in projects/cps-ui-kit/styles/_mixins.scss and the :focus-visible rule in cps-dialog.component.scss around line 107. Reproduce by opening the draggable dialog example, clicking the header, pressing ArrowDown, and checking that elementFromPoint returns the dialog instead of the button. Done when the ring's pseudo-elements do not take clicks, the ring looks unchanged, and a Playwright spec beside the focus-ring tests clicks Close dialog successfully.
Written by the indexing model from the issue text.
Description
Summary
When a cps-dialog has keyboard focus on its frame, the focus ring drawn around the dialog covers the whole dialog and takes every pointer event. Buttons, inputs and links inside the dialog stop responding to clicks until the focus moves elsewhere.
The state is easy to reach: click on the dialog's header, then press a key. The click focuses the dialog frame (div.cps-dialog[tabindex="-1"]), and the key press makes the browser treat that focus as keyboard focus (:focus-visible matches), which turns the ring on.
Environment
cps-ui-kit21.33.0. The source of 22.3.0 has the same CSS for this ring, but I did not run that version.- Reproduced in Chromium and WebKit (automated browsers).
- Reproduced on the kit's own documentation site, so it does not depend on any application code. I do not know which kit version the site is currently built with.
Steps to reproduce
- Open https://absaoss.github.io/cps-shared-ui/dialog/examples and click the Draggable dialog button.
- In the dialog, click Disable closing. This stops Esc from closing the dialog, which would otherwise hide the problem. (Skipping this step and pressing ArrowDown in step 4 gives the same result.)
- Click on the dialog's header, in a bare part of it.
- Press Esc (or ArrowDown).
- Click anything inside the dialog, for example the Close dialog button.
Expected
The dialog shows its focus ring, and everything inside it still responds to clicks.
Actual
The dialog shows its focus ring, but clicks on everything inside it do nothing. The cursor behaves as if the dialog were one inert block.
Observed in the browser after step 4:
document.activeElementisdiv.cps-dialog, and.matches(':focus-visible')istrue.document.elementFromPoint(...)at the centre of the Close dialog button returnsdiv.cps-dialog, not the button.getComputedStyle(dialog, '::before')iscontent: "",inset: -1px,border: 1px solid,pointer-events: auto.::afteris the same withinset: -2px.- Playwright's click on the button fails with:
<div role="dialog" tabindex="-1" data-testid="cps-dialog" ... class="cps-dialog ..."> intercepts pointer events.
Cause
The dialog frame's focus ring comes from the focus-ring mixin:
projects/cps-ui-kit/src/lib/services/cps-dialog/internal/components/cps-dialog/cps-dialog.component.scss, around line 107:&:focus-visible { @include focus-ring(0.0625rem, 0.125rem, inherit); }projects/cps-ui-kit/styles/_mixins.scss,@mixin focus-ring: it setsposition: relativeon the element and draws the ring with::beforeand::after, bothposition: absolutewith a negativeinsetand a border.
On a small control that is harmless. On the dialog frame the two pseudo-elements are as large as the whole dialog. They are positioned, so they paint above the dialog's non-positioned content, and because pointer-events is left at its default they become the hit-test target for every point inside the dialog.
Esc is only one way in. A dialog whose closeOnEscape is false (or disableClose is set) stays open after Esc, so it is the clearest repro, but any key press after the header click does it: ArrowDown works on the docs site in both browsers. In WebKit, Shift alone does not turn the ring on, but ArrowDown and Esc do.
Suggested fix
The ring is decorative, so it should never be a pointer target. The smallest change is in the mixin, which also protects every other component that uses it:
&::before,
&::after {
content: '';
position: absolute;
pointer-events: none; // the ring is decorative and must never take clicks
border-radius: $radius;
}
If changing the mixin is too broad, put the same pointer-events: none on the ring's pseudo-elements for the dialog frame only.
The ring must stay visible; only its pointer behaviour changes. Other uses of the mixin on large containers (for example the resizable handles in the same file, around lines 195 and 285) may be worth checking for the same effect. I did not test those.
Acceptance criteria
- After clicking the dialog header and pressing Esc (with
closeOnEscape: false) or ArrowDown, buttons and inputs inside the dialog can be clicked. - The focus ring is still drawn exactly as before.
- A Playwright test covers it, next to the existing focus-ring specs under
playwright/cps-ui-kit/components/: open the draggable dialog example, click the header, press ArrowDown, then click Close dialog and expect the dialog to close.
Workaround for applications
.cps-dialog:focus-visible::before,
.cps-dialog:focus-visible::after {
pointer-events: none;
}
- Dominant language
- TypeScript
- Stars
- 9
- Forks
- 8
- Avg merge
- 1d 6h
- Merged PRs (30d)
- 25
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from AbsaOSS/cps-shared-ui
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
AbsaOSS/cps-shared-ui#875 ·
Maintainers usually reply within 1 day
-
InputComponent - expand type beyond text/number/passwordMay be free again A pull request for this issue was closed without being merged. Openenhancement library
Difficulty 1/5 Under an hour Newbie friendliness 85/100
AbsaOSS/cps-shared-ui#644 ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 3/5 1-2 days Newbie friendliness 35/100
AbsaOSS/cps-shared-ui#951 ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 62/100
AbsaOSS/cps-shared-ui#950 ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 Half a day Newbie friendliness 55/100
AbsaOSS/cps-shared-ui#949 ·
Maintainers usually reply within 1 day
All issues in AbsaOSS/cps-shared-ui
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
jeanibarz/knowledge-base-mcp-server#1268 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
Koenkk/zigbee-herdsman-converters#13820 ·
Maintainers usually reply within 2 days
-
[prefer-expect-resolves] autofix leaves a stray ")" when the awaited expression is parenthesizedOpen
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
jest-community/eslint-plugin-jest#2052 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Wallet functions throws TypeError when the wallet has no account IDPossibly taken @Medhansh-741 claimed this today. Openbug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
hiero-ledger/hiero-sdk-js#4781 · 1 comment ·
Maintainers usually reply within 1 day