Browser

The Browser block works a site the way a person does. The page opens in a real Chromium browser (the engine behind Google Chrome), so content that only appears after JavaScript runs is visible. A plain HTTP request to the same address often returns an empty shell.

On the canvas you pick one Action. The other fields follow from that choice. Block type: browser.

Two modes

• Exact actions — you name the step: open an address, click an element, type text, take a screenshot. One block is one action. Several blocks can share one session (the id of a browser left open, so the next block continues on the same page).
• Model-driven task — you describe the goal in Task. The model reads each page and chooses the next step, keeping one browser open for the whole run.

Inputs shared by every action

These fields appear on every action. Session and Keep the browser open sit in the block's advanced mode.

The block needs Address or Session. Both empty means there is no page to work on.

Exact actions

By default each exact action opens a fresh empty browser and closes it afterwards: the login, cookies (small data the site uses to recognize a signed-in user), and a half-filled form are gone. So Address is required unless you pass a session.

One extra field is shared by exact actions (a task has no such field — the model decides when to wait):

Open page (browser_navigate)

Loads the address and returns what the page contains.

Input

No extra fields — the shared parameters are enough.

Output

Pass <browser1.content> to an Agent block to extract the part you need.

Click (browser_click)

Clicks an element and returns the page that results.

Input

Output

Same fields as Open page.

Type text (browser_type)

Types into a field. Useful for search boxes and for filling a form one field at a time on a shared session.

Input

Output

Same fields as Open page.

Screenshot (browser_screenshot)

Photographs the page. The image comes back as a data URI (the picture embedded in a string). The Vision block and the Agent can read it directly.

Input

Output

Same fields as Open page, plus:

How to copy a selector

1. Open the same page in your own browser.
2. Right-click the element → Inspect.
3. Right-click the node in the inspector → Copy → Copy selector.
4. Paste the value into Element.

A short selector by id or field name (button#login, input[name='q']) survives layout changes better than a long chain such as div > div:nth-child(3) > span.

Chain blocks on one session

Log in in one block, fill a form in the next, read the result in a third — all on one live browser. The rule: every block except the last has Keep the browser open turned on, and each next block receives the previous sessionId.

1. First block: set Address, turn on Keep the browser open. The outputs include sessionId.
2. Later blocks: put <browser1.sessionId> in Session (use your block name). Leave Address empty to stay on the current page. If you do set an address, the browser navigates there first.
3. Last block: leave Keep the browser open off. The browser closes; sessionId is absent from the output.

Browser 1  Type text (login)     Address: https://portal.example/login   Keep open: yes
Browser 2  Type text (password)  Session: <browser1.sessionId>           Keep open: yes
Browser 3  Click “Sign in”       Session: <browser2.sessionId>           Keep open: yes
Browser 4  Open orders page      Session: <browser3.sessionId>           Keep open: no

Know this before you chain:

• An idle browser does not wait forever. After 5 minutes with no return visit it closes and the session id stops working. Each use restarts the timer.
• At most 10 browsers wait at once. A new eleventh one evicts the browser that has been idle the longest.
• A failed action closes the browser. There is nothing to continue in.
• An unknown or expired session is a clear input error: the browser is no longer open. The same happens after an application restart — the open-browser list lives in process memory and does not survive a restart.
• A model-driven task can hand the same session to a follow-up task — see two-factor login below.

Model-driven task (browser_run_task)

Run a task (AI) works the other way around: you do not list clicks, you write the goal. The model reads each page, chooses the next step, and answers in words. One browser stays open for the whole run, so a login and the work behind it are a single block.

The answer comes back in the language the Task was written in.

Write a checkable outcome, not a click script. Include the goal, the inputs and constraints, which site changes are allowed, the visible done condition, what to return, and when to stop for a person. Keep the start URL in Address; do not paste it into the task. Do not put literal passwords or tokens in the task. Do not invent selectors or internal action names — the model reads the open page.

Poor: “Open the site, click the first button, then the second, and check the order.”

Better: “Find the last paid order for customer <start.customerId>. Change nothing. The task is done when the order page shows the number, status, and payment date. Return those three values. If a login or confirmation that is not in the current session is required, stop and ask a person.”

Input

Session and Keep the browser open are only for handing the same page to the next block. Inside one task the browser already stays open between steps. There is no Wait for text field on a task.

The model can open pages, click, type, fill a form, wait, search the page, switch tabs, take a screenshot for itself, finish, or ask a person. It cannot run arbitrary code on the page or send arbitrary requests with the session cookies.

Output

A normal successful finish does not return a screenshot: a picture of a private cabinet would sit in the run log, so the block only sends one when a person cannot proceed without it.

If later blocks must read fields instead of parsing text, set Answer format:

{
  "type": "object",
  "properties": {
    "order_number": { "type": "string" },
    "status": { "type": "string" },
    "delivery_date": { "type": "string" }
  },
  "required": ["order_number", "status"]
}

The run then returns both answer and data with the same values as fields.

Task statuses

Two-factor login with two tasks

A single task cannot pass “confirm in the app”: it stops with needs_human. You can hand the still-open page to a second task.

1. Task 1 — “sign in and stop on the confirmation screen.” Turn on Keep the browser open. The output includes sessionId.
2. Confirm the login on your phone. You have 5 minutes of session idle time.
3. Task 2 — paste that sessionId into Session, leave Address empty, and write in Task what to do next.

What the block cannot do

• It does not open URLs with a login and password inside the address (https://user:pass@…).
• It does not open the internal network (127.0.0.1, 192.168.*, hostnames without a dot). An internal portal is an installation setting, not a block field.
• It does not run arbitrary code on the page or send arbitrary requests with the session cookies.
• It does not remember the page after a failed action, after 5 idle minutes, or after an application restart.
• It is not as stable as an API integration: a layout change can break an exact-action selector. A task usually follows button labels, but that is still not a contract.
• It is a poor fit for “click forty times”: the step limit is a ceiling, not a target. On a known page, exact actions are faster and more predictable. A task run takes minutes, not seconds.

Examples

Read a public page

Start → Browser (Open page) → Agent (pick fields) → Response

Sign in and read a cabinet with exact actions

Browser (type login, keep open) → Browser (type password, session) → Browser (click Sign in, session) → Agent

A goal in words, structured data for the next block

Browser (Run a task, Answer format) → Condition on status → Function or a channel