@sungen/driver-ui 3.2.16-beta.7 → 3.2.17

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sungen/driver-ui",
-  "version": "3.2.16-beta.7",
+  "version": "3.2.17",
   "description": "Sungen UI capability (Playwright) — step patterns, viewpoint gate, and phase hooks. Plugs into @sun-asterisk/sungen via the capability SPI.",
   "main": "src/index.ts",
   "types": "src/index.ts",
@@ -13,7 +13,7 @@
   "author": "eqe team (engineer & quality) — Sun Asterisk",
   "license": "MIT",
   "dependencies": {
-    "@sun-asterisk/sungen": "3.2.16-beta.7"
+    "@sun-asterisk/sungen": "3.2.17"
   },
   "peerDependencies": {
     "@playwright/test": "^1.57.0"

package/src/patterns/interaction-patterns.ts

@@ -125,6 +125,67 @@ export const interactionPatterns: StepPattern[] = [
     },
     priority: 20,
   },
+  {
+    // `try to click [X] button` — the DISABLED-element probe (issue: no way to write
+    // "click a disabled control and confirm nothing happens").
+    //
+    // A plain `click` compiles to Playwright's `.click()`, which auto-waits for the element to
+    // be ACTIONABLE (visible + enabled + stable). That wait is the whole point for a real click,
+    // but it makes the inverse scenario — "the re-send link is in cooldown, clicking it must do
+    // nothing" — impossible to express: the step can only ever time out on an element that is
+    // disabled BY DESIGN.
+    //
+    // This variant bypasses the actionability wait (`{ force: true }`), so the click is really
+    // dispatched at the element's position. A natively-`disabled` control swallows it and nothing
+    // happens (the following assertions prove that); an `aria-disabled`/CSS-only "disabled"
+    // control that still handles the click is caught as the bug it is. Note the element must
+    // still exist and be rendered — this is not a silent no-op.
+    //
+    //   When User try to click [Re-send] link          # cooldown active → must stay inert
+    //   Then User see [Re-send] link is disabled
+    //   And User see [Cooldown] text                   # …and no re-send happened
+    name: 'try-click-element',
+    matcher: (step: ParsedStep) =>
+      /\b(?:tr(?:y|ies)|attempts?)\s+to\s+click\b/i.test(step.text) &&
+      // `… and accept/dismiss [OK] alert` stays with click-with-alert: force-clicking here would
+      // drop the page.once('dialog') listener the compound form exists to register.
+      !/\band\s+(?:accept|accepts|dismiss|dismisses)\s+\[[^\]]*\]\s+alert\b/i.test(step.text) &&
+      !!step.selectorRef,
+    resolver: (step, context) => {
+      const resolved = context.selectorResolver.resolveSelector(
+        step.selectorRef!, undefined, step.elementType, step.nth
+      );
+
+      // No `with {{v}}` → plain forced click. Mirrors click-element.
+      if (!(step.dataRef || step.value) || !step.text.includes('with')) {
+        return {
+          templateName: 'click-action',
+          data: { ...resolved, selectorRef: step.selectorRef, force: true },
+          comment: `Try to click ${step.selectorRef} (bypasses the enabled/actionability wait)`,
+        };
+      }
+
+      // `with {{v}}` → filter to the matching row/item first. Mirrors click-element-with-text.
+      let dataValue: string;
+      if (step.value) {
+        dataValue = step.value;
+      } else {
+        try {
+          dataValue = context.dataResolver.resolveData(step.dataRef!, context.featureName);
+        } catch {
+          dataValue = `\${${step.dataRef}}`;
+        }
+      }
+      const { name: _name, ...resolvedWithoutName } = resolved;
+
+      return {
+        templateName: 'click-element-with-text',
+        data: { ...resolvedWithoutName, dataValue, force: true },
+        comment: `Try to click ${step.selectorRef} with text ${step.dataRef || step.value} (bypasses the enabled/actionability wait)`,
+      };
+    },
+    priority: 22,  // above click-with-alert (21) and every other click pattern — the verb wins
+  },
   {
     name: 'unknown-element-action',
     matcher: (step: ParsedStep) => {