App-creation wizard is unusable: Next is unclickable — the dialog's own subtree intercepts pointer events

[rubenvdlinde]

Symptom

Every scenario in tests/e2e/createApplicationWizard.spec.ts fails — 8/8, reproducibly, in isolation. The wizard cannot be advanced past the step where Next is first clicked (tests/e2e/createApplicationWizard.spec.ts:159).

This is not a test-only problem: the wizard is the primary way to create an application.

What the failure actually says

The button is fine. The click never lands:

waiting for getByRole('button', { name: /^next$/i }).first()
  - locator resolved to <button type="button" class="button-vue button-vue--size-normal button-vue--secondary">
  - attempting click action
    - element is visible, enabled and stable
    - scrolling into view if needed / done scrolling
    - <div class="dialog__actions"> from <div role="dialog" aria-modal="true"
        data-testid="cn-modal" data-testid-modal="cn-wizard-dialog" class="dialog__modal modal-mask">
      subtree intercepts pointer events
  - retrying click action
    - <div class="modal-wrapper modal-wrapper--large"> … subtree intercepts pointer events
  [retries until the 30s timeout]

Next is visible, enabled and stable the whole time. Something in the dialog's own subtree — dialog__actions on one retry, modal-wrapper--large on the next — sits above it and swallows the click. The alternation between the two suggests a stacking/overlay problem rather than one specific element.

Ruled out

• Not a stale bundle. First observed against the bundle deployed 2026-07-31, then reproduced after a clean npm run build from current development and a redeploy (bundle rebuilt 2026-08-02, verified Vue 3.5.40 / vue-router 4.6.4). Identical failure, 8/8.
• Not test interference. Fails the same way when the spec runs alone as it does in a full-suite run.
• Not flake. Every run, every scenario, same call log.
• Not RBAC. Runs as admin, and reproduces both before and after the read: ["authenticated"] grant in fix(rbac): grant authenticated read on every openbuild schema (#76) #81.

Where to look

data-testid-modal="cn-wizard-dialog" — the wizard renders inside a CnDialog/NcDialog. Two candidates worth checking first:

1. A second modal mask stacked over the first (two dialogs mounted at once), so the topmost modal-mask covers the actions bar of the one below.
2. dialog__actions overlapping its own button row — a layout/z-index regression in the dialog chrome.

A DOM dump of .modal-mask / .dialog__modal element count at the moment of failure would settle which.

Scope note

Found while running the full e2e suite for #81/#84. Not caused by that work — filed rather than fixed, because the fix is a dialog-layering investigation rather than part of the RBAC change.

Full-suite context: 162 passed, 21 failed, 74 skipped (48.6m). These 8 are the largest single cluster.

[rubenvdlinde]

Re-verified against the correctly-pinned library — still 8/8

Correcting the evidence in the original report. I said staleness was ruled out because I rebuilt from current development. That was only half true: the app code was fresh, but node_modules held @conduction/nextcloud-vue@2.1.0-vue3.7 while package.json and the lockfile both pinned 2.1.0-vue3.13. No install had been run since that bump, so the reproduction linked a library three versions behind the pin.

Re-run after a clean npm ci at 2.1.0-vue3.15 (via #87), rebuilt and redeployed:

8/8 fail, identically. Next is visible, enabled and stable; dialog__actions / modal-wrapper--large intercept the click until the 30s timeout.

So the conclusion stands and is now properly evidenced — this is not an artefact of a stale @conduction/nextcloud-vue. The dialog-layering investigation in the original report is still the way in.