Windows Computer Use: Storyline state dropdown click can submit underlying dialog; fresh UIA operations fail with cache errors

Environment

• Codex Windows AppX package: 26.901.5280.0 (package metadata).
• Bundled Windows Computer Use plugin: 26.901.41600.
• Articulate Storyline 360 x64: file/product version 3.124.37782.0.
• Windows OS version: 10.0.26200.0.
• Supported @oai/sky window2 APIs through persistent node_repl.
• Storyline's title includes “Administrator”; helper/target integrity levels have not been measured.
• No private project, screenshots, account details, or conversation transcripts attached.

Summary

A screenshot-based click on an item in Storyline's “Add” state-name dropdown can close the popup without selecting its value, or unexpectedly confirm the underlying dialog and create a state with the unchanged default name. Direct UIA operations on freshly observed dialog elements fail with cache errors.

This is a Storyline-specific reproduction related to #42899 and #43072, not a claim of an independently confirmed internal root cause. Unlike #42899, our focus metadata did NOT prove that a key action moved focus to the disabled owner. It continued reporting the dialog edit field.

Controls that succeeded

1. Windows Notepad settings: font style Regular → Italic → Regular, all screenshot-based clicks visually verified.
2. Notepad modal Save As dialog: file type Text documents → All files → Text documents; verified, then canceled without saving. The modal was NOT separately returned by list_windows, yet targeting the returned Notepad window worked.
3. Same Storyline process, main-window font-size dropdown: 24 → 20 visibly applied, then undone to 24.

Thus neither all dropdowns nor all modal dialogs fail, and main-window input into Storyline works.

Reproduction

Use a disposable Storyline project because a selection click may unexpectedly submit the dialog.

1. Add/select a button and enter Edit States. In the tested object, the standard states including Selected already existed.
2. Select the actual Storyline Window from list_windows, activate it, and capture fresh state.
3. Click New State (the earlier Duplicate State path showed similar selection failures). The Add dialog opens with default name “New State” (German: “Neuer Zustand”).
4. Reobserve after opening: the first immediate accessibility result may still describe main-window focus; a subsequent observation includes AddOrDuplicateShapeStateForm, comboBoxName and edit AutomationId 1001.
5. Open the state-name dropdown via a fresh screenshot-based click and inspect the resulting screenshot.
6. Click the visible “Drag Over” (“Ziehen über”) entry. In the tested layout that row overlapped the underlying Add button.
7. Observed in the latest run: the entire dialog closed and a state named “Neuer Zustand” was created, instead of merely selecting “Ziehen über” and leaving the dialog open. Earlier trials closed only the list while leaving its value unchanged.
8. The unintended test state was immediately undone and the original six states visually verified. No file was saved.

All inputs used observed coordinates and refreshed screenshots, one action followed by observation. Coordinates are layout-dependent and should not be copied from another machine.

Direct UIA alternatives also fail

The dialog is visible in the main window's accessibility tree but is not separately listed as a targetable Window. No handles were invented.

After observing the dialog's advertised secondary action:

await sky.perform_secondary_action({
  window: observation.window,
  element_index: dialogIndexFromLatestTree,
  action: "Raise"
});

Result:

element 9308 has no cached secondary actions for Storyline.exe

After another fresh observation, set the edit field to its existing value (no intended change):

await sky.set_value({
  window: observation.window,
  element_index: editIndexFromLatestTree,
  value: "Neuer Zustand"
});

Result:

read UIA value read-only state: Die angeforderte Eigenschaft war nicht im CacheRequest enthalten. (0x80070057)

Translation: requested property was not included in the CacheRequest.

Other freshly observed element accesses also returned:

element ... is not available in cached app state for Storyline.exe

A single Down key after observing dialog focus did not change the value. The text selection disappeared, but focus metadata still named the same edit field.

Recovery and limits

Fresh window selection, JS kernel reset/reimport, and a user-confirmed full Codex restart did not resolve the prior failures. Manual dropdown selection worked according to the user; the resulting Selected state was visible and preserved. During the latest autonomous comparison, the user had stepped away; after explicit Storyline activation we did not observe unrelated app screenshots. Earlier screenshots of Codex are not evidence of a capture bug because the user had been switching windows.

Hypothesis: activation/targeting may dismiss the popup before dispatching the click, allowing it to reach the underlying Add button. The outcome is consistent with this, but internal ordering has NOT been observed. The relationship to the UIA cache errors also remains unproven.

Expected

A click on a visible popup item should select that item, not activate a covered button. Freshly advertised UIA controls/actions should remain usable in the documented observe-then-act workflow, or return an actionable unsupported-control explanation.

Final project state

No dialog open; original states and font size restored; no file saved. Undo/redo history was affected by reversible tests.

Start with the @oai/sky operations used through the persistent node_repl, especially list_windows, observation, screenshot-based clicks, perform_secondary_action, and set_value. Reproduce the Storyline Add State dropdown flow with a disposable project and fresh observations. Done means the visible item selects without submitting the underlying dialog, and freshly advertised UIA controls either work or return an actionable unsupported-control explanation.