Limits: what HailBrowser cannot do yet

• Shadow DOM, cross-origin iframes, canvas apps, file uploads and pop-up windows are not fully supported yet.
• Research cannot read PDFs yet, so sources that only exist as PDFs are skipped.
• Scheduled jobs only run while Chrome is open, and a job that came due while Chrome was closed runs once at the next start.
• One run happens at a time. Scheduled jobs that come due during another run wait in a queue.
• Ultrafast sees on-screen elements only and scrolls to find more.
• A model DONE is a claim, not proof. Verify outcomes that matter.
• chrome:// pages and the Chrome Web Store cannot be automated because Chrome blocks it.

Pages it cannot drive

Shadow DOM

Elements inside a closed or deeply nested shadow root are not in the indexed list. Some can be reached with the JavaScript tool if you know the host; most cannot be clicked reliably.

Cross-origin iframes

An embedded payment form or login widget from another origin exposes nothing to the page script. HailBrowser reports the iframe but cannot read or type inside it.

Canvas apps

A canvas has no elements to index. Screenshot coordinates still work, but the model is clicking a picture, so accuracy depends on the picture being unambiguous.

File uploads

There is no file picker tool. A form whose next step needs a file will stop there.

Pop-up windows

A new window is not the same as a new tab. Tabs that open from a click are named in the result; separate windows are not always followed.

chrome:// pages and the Chrome Web Store

Chrome blocks the debugger on its own pages and on the store. This is a browser rule, not a missing feature, and it will not change.

Research

Research cannot read PDFs yet. If the best sources for a question only exist as PDFs, the report will either be thinner or lean on secondary summaries. It also cannot log in for you: it uses the session your browser already has.

The citation rule is strict: a claim without a source that exists is dropped. That makes reports conservative, and it means a vague answer usually reflects weak sources rather than a lazy model.

Scheduled jobs

• Schedules use chrome.alarms, which only fire while Chrome is running.
• A job that came due while Chrome was closed runs once at the next start, not once for every missed interval.
• One run happens at a time. Jobs that come due during another run wait in a queue.
• A scheduled job will not send, buy, post or delete anything unless the goal says so. If it needs a decision, it reports what needs you instead of waiting forever.

Fast mode

Fast sees only the elements currently on screen, and scrolls to find more. A control that is hidden behind a hover menu, or that only appears after a long animation, can be missed. It can open a site only when your goal names it: a URL, a domain, or a well-known name.

It also does not plan. If a form has a branch that depends on a value (“if you are outside the EU, fill this instead”), the decision model has to discover the branch one step at a time.

Answers and done claims

A model saying DONE is a claim, not proof. Fast mode asks for a second yes/no check before reporting success, which catches the obvious cases and not all of them. If the outcome matters, verify it: read the confirmation page, check the order, look at the sent mail.

Questions are answered from the final page. When the page does not say, the answer says so rather than filling the gap.

What to do instead

• For a login wall: sign in yourself first. The run uses that session.
• For a payment or a CAPTCHA: let the task stop and ask. That is the designed behaviour.
• For a canvas or an iframe: use a screenshot and coordinates, and check the result, or do that one step by hand.
• For a PDF: download it and read it, or ask Research for HTML sources on the same question.
• For a job that must run without Chrome open: it cannot, yet. Keep Chrome running or run the job when you are at the machine.