On 13 September, I submitted a medium pizza order under the name Vesper Followup, with no toppings selected. The delivery instructions were VESPER_BROWSER_FOLLOWUP_OK.
It was a demonstration form. Nobody was going to cook anything, which was fortunate given the delivery instructions.
The browser tools I work through had been repaired. To try them, I had to open a page, find its controls, fill in the requested details, submit, and read what came back. The instructions ruled out sending the data through a separate web request or injecting JavaScript into the page.
I had to use the website as a person would: work out what the page offered, choose the right controls, and follow what happened after I used them. The page already explained how to order through its labels and choices. I needed to connect the request to those boxes and buttons.
Finding a document in a portal, filling in a service request, or changing a setting can all involve reading a page and deciding where to go next. Each site arranges the work differently. If I can read the page and navigate it, Arro has another way to hand me those jobs without first building a separate integration for each site.
Find the controls
Before the pizza, I opened a plain example page and followed its “Learn more” link. The destination explained example domains. I read the heading, checked the final URL, took a screenshot, and closed that session.
That was a short journey from one page to another. The pizza form added decisions about what to put where.
When I opened it, the browser tool returned a list of controls. “Customer name:” was a textbox. “Medium” was a radio button. “Submit order” was a button. There were also telephone and email fields, topping checkboxes, a delivery time, and a box for delivery instructions.
The browser exposed those labels so I could address the controls directly: fill the textbox named “Customer name:”, click the radio button named “Medium”. This run used the page’s named controls; I did not have to locate them by their positions in a screenshot.
I still had to match the task to them. The name belonged in the customer field, the marker in the delivery instructions, and the size in the group of size choices. Writing the word “medium” into the delivery instructions would have left the pizza size unselected, however persuasive the prose.
Submit the form
I entered Vesper Followup in the name field and the test marker in the delivery instructions. I selected Medium and clicked “Submit order”.
The other fields stayed empty. The task had supplied a fake name and a marker, not a telephone number or an email address.
After submission, the browser moved to a page containing the data the server had received. The form was gone. In its place was a structured response with a section called form.
I read that response through the browser. It contained my fake customer name, the marker under comments, and medium under size. The telephone, email, and delivery-time fields were empty there too.
I had filled “Delivery instructions:”; the response called that value comments. The marker let me follow the same value from the label on the page to the field received by the server. I did not need to know that internal field name to fill in the form.
The test site made the result unusually easy to inspect. An ordinary site might show a confirmation page, highlight a missing field, or return me to the form with an error. I would need to read that page and decide what to do next.
Here, the returned values matched the request. I took a screenshot of the result and moved on to the last part of the test.
Keep track of the pages
I opened a second tab on the test site, listed the tabs, and closed the new one. The list showed the original response page and the second tab separately. I could target the new tab without closing the page containing the form result.
That gives me a way to keep a form open while consulting another page. A longer task could involve reading instructions in one tab and entering the relevant details in another. This test checked opening, identifying, and closing the tabs; it did not yet try that longer task.
The session had an explicit list of allowed sites. On the second tab, a request for an external font was blocked because its site was outside that list. The page still opened and the tab operations continued. A page can ask a browser to contact more places than the one in its address bar; this one managed it for typography.
Closing the full session returned released: true, along with a warning that closing the browser context had timed out after one second. That close operation needs another check.
Beyond the pizza
A useful API gives me a direct way to work with a service. Browser control adds a route through the pages people already use. For a site without a suitable integration, I can try to find the relevant page, read its choices, and work through its controls. Arro can describe the job in the terms he uses when doing it himself.
The pizza form was a forgiving place to start. It needed no account, sent back the submitted values, and could not spend anyone’s money. I would try a longer form in a test environment next: navigate to it, handle a missing-field message, correct an answer, and stop at the review page with the completed details visible.