The page never finishes loading, whatever timeout you set

Ten seconds fails. Forty-five seconds fails identically. The target is not slow — it is never going to be finished, and no timeout will change that.

The symptom. TimeoutError on the initial navigation. You raise --timeout from 10 s to 45 s. It fails again, in exactly the same way.

That identical failure is the diagnosis: this is not a duration problem.

What Dinoer is waiting for

By default, navigation completes on networkidle — 500 ms of network silence. That is a good default: it means the page has genuinely settled, scripts have run, content has arrived.

Some targets never go silent. A dashboard refreshing counters, a live statistics panel, a router administration interface polling its own status — they keep talking to the network by design. There is no moment of quiet to wait for, so Dinoer waits until the timeout, every time, at any duration.

Change the condition, not the duration

/opt/dinoer/venv/bin/python3 /opt/dinoer/shot.py \
  --url http://target.local/ --wait-until load --a11y \
  --guide-version 1.6

--wait-until load completes when the page’s own load event fires, without requiring network silence. The same flag exists on rpa.py and is propagated to campaign-driven escalations.

A scenario can carry it as a root property, so it stays self-contained — the person who reuses your scenario does not have to know the target’s quirk:

{"url": "http://target.local/", "wait_until": "load", "actions": [...]}

The command line wins over the scenario Unlike boolean options that combine, this one carries a value — and two values do not add up. If both are set, the flag decides.

Which value to use

Value	Completes on	Use it when
`networkidle`	500 ms of network silence	the default — keep it unless it fails
`load`	the page’s load event	the target polls continuously
`domcontentloaded`	HTML parsed, subresources pending	you need the earliest possible view

Do not reach for load pre-emptively. The default gives you a page that has finished arriving; changing it means accepting that some content may still be in flight when the answer is produced. Change it when the default fails, not before.

How to tell this apart from a slow page

A slow page succeeds if you wait long enough — raising the timeout changes the outcome. A never-idle page fails identically at every duration.

So the test is cheap: run it twice, once at the default and once at a much larger timeout. Same failure, same speed? Change the condition. Different behaviour? You have an ordinary slow target, and the timeout is the right dial.

In short

Identical failure at 10 s and 45 s = wrong condition, not wrong duration.
--wait-until load for targets that poll continuously.
Put it in the scenario so it travels with the target.
Keep networkidle everywhere else.