The window synchronizer

The synchronizer sits in the manager under Automation. You pick one running profile as the master and tick one or more running profiles as targets. From the moment you press start, your clicks, typing, scrolling and address changes in the master window are repeated in every target window.

You keep doing the work with your own hands. The program only copies what you did into the other windows. Nothing is scripted in advance and nothing runs without you.

It needs at least two profiles already open. With fewer, the screen says so and sends you to the profiles list. On a plan that includes only one profile it says that instead and links to the plans page, because opening a second profile would be impossible.

Only one session runs at a time. Starting a new one stops the previous one. The status bar counts the windows that are currently following you and updates itself when a target window closes.

• Clicks

  The element under the pointer, plus where inside the window you hit.

• Typing

  Text entered into a field that has a value.

• Scrolling

  The page position, sent at most once every 120 ms.

• Nine navigation keys

  Enter, Tab, Backspace, Delete, Escape and the four arrows.

• Address changes

  Navigation in the main frame of the master window.

Capture happens inside the master page, not by reading the mouse at the level of the operating system. Four listeners sit on the document in capture phase: click, scroll, input and keydown. Only the master is ever armed, so a normal window stays completely untouched.

On the built-in Chromium engine those listeners live in the profile preload. The main process arms them with one message and arms them again after each navigation, because the preload reloads on every committed document. Each action is relayed over IPC, and the main process accepts it only when the sender is the master's own window.

ARMANOS Browser 153.0.7978.0 has no preload of ours, so the same listeners are injected into the page over the debug protocol. They put actions into a queue inside the page, and the main process empties that queue every 120 ms. Polling is a deliberate choice: receiving events from the protocol would need Runtime.enable, and page script can tell when that is on.

To survive a navigation the agent is also registered as an on-new-document script. That registration only takes effect with the Page domain enabled, which was found by measuring against the built engine, not by reading documentation. The domain is switched on for the length of the session and off again when you stop.

A captured click is not a pixel. The agent builds a short CSS path for the element you hit. An id wins outright. Otherwise it walks up at most five levels, naming each step by tag and position among siblings of the same tag, and stops early at the first ancestor that has an id.

It also stores where inside the window you clicked, as two fractions. The x is your click divided by the master's inner width, the y by its inner height. Those fractions are the fallback, and they are what lets a target window of a different size still receive the action in a sensible place.

Typing is stored as the element path plus the whole current value of the field, not as a stream of keystrokes. Scrolling is stored as absolute coordinates. Navigation keys are stored by name and mapped to key codes on the way out.

In each target the click is tried by selector. The element is scrolled to the centre of the view and then clicked. This is the path that survives a target window of another size, a page that has shifted, or a banner that pushed everything down.

If the selector finds nothing, the fractions take over. They are resolved against the target's own inner width and height, not against its window frame, because that is what they were measured against in the master. A mouse move, a press and a release are sent at that point.

On ARMANOS Browser those input events travel through the debug protocol. On a profile dressed as a phone the press and release are sent as touch instead. The engine turns mouse into touch on such a profile, and a real phone sends no mouse events at all.

A target that navigated a moment before the action simply misses it. Nothing is retried and nothing is held for it, because a held action would land on a page you were no longer on.

A profile usually opens with two tabs. The ARMANOS start page comes first, then the address you asked for, and you go on to work in the second one.

Until 29 August the synchronizer took the first tab by order of appearance, which was the start page. A live measurement on the built engine showed the result plainly: the master clicked twice and scrolled to 600, the target showed zero and zero. The tab is now chosen by asking the pages themselves which one is visible.

The choice is made once, when you press start, and remembered for the master and for every target. Recomputing it on each action would risk half your actions landing in one tab and half in another.

Navigation is mirrored on its own path. On the built-in engine the master window reports it to the main process. On ARMANOS Browser the same 120 ms loop compares the master address with the last one it saw. Blank pages, error pages and devtools addresses are never forwarded.

1. 1

   The visible tab of the master is found

   Each of its pages is asked whether it is the visible one, and the answer comes from the engine rather than from our guess about order.

2. 2

   The same question goes to every target

   A target with no page to answer is dropped before the session starts. If none are left, start fails and says so.

3. 3

   Capture is armed in the master alone

   If arming fails, the session does not begin. A half started session would look active and mirror nothing.

4. 4

   The chosen tabs are remembered

   Every later action goes to those exact tabs, and only falls back to another tab if the chosen one is gone.

5. 5

   The status bar starts counting

   It shows how many windows are following, and it drops the count as target windows close.

Mirroring is only useful if you can watch what happened. The manager has an Arrange windows button, and it appears as soon as more than one profile is running.

The grid is built on the display where your cursor is, inside its work area. Columns are the square root of the window count rounded up, and rows follow from that. Cells are separated by a gap of six points. If a cell would come out smaller than 420 by 320, the program refuses and says why, instead of laying out windows nobody can read.

Windows of the built-in engine are moved by the shell. Windows of ARMANOS Browser are separate processes the shell cannot touch, so they are moved through the debug protocol, which sees a browser window as an object. A minimized or maximized window is set back to normal first, otherwise the engine refuses the new size without a word.

Both kinds share one grid, counted in one place, so windows of our own engine do not land on top of built-in ones. A profile started without a window is skipped: it would take a cell and leave a hole. The new place is written into the profile, so it is still there at the next launch.

Windows open

6

Columns and rows

3 by 2

Display work area

2560 by 1440

Gap between cells

6

Resulting cell

845 by 711

Worked through the same formula the code uses. Below 420 by 320 per cell the answer is a refusal, not a grid.

If the master window closes, the whole session stops. If a target window disappears, it drops out of the set and the counter falls. When the last target is gone, the session ends by itself rather than mirroring into nothing.

Pressing Stop disarms capture. On the built-in engine the master is told to detach its four listeners. On ARMANOS Browser the on-new-document script is removed, the queue is disarmed and emptied, the random global name is deleted from the page, and the Page domain is turned off again.

Nothing is written down. A session leaves no recording, no list of the actions it carried and nothing you can play back later.

The synchronizer is for work you are doing anyway, once, with your eyes on it. Accepting the same cookie banner in eight accounts. Filling the same profile form. Walking the same checkout to the same step. Your judgement stays in the loop, and you see each window as it goes.

A flow in RPA Plus is for work you will do again. It has steps, conditions, variables, a value matrix per profile, a schedule and a run log. It can run without you sitting there. It costs more to write and far less to repeat.

A rule of thumb that holds up: if you would do it more than twice, write a flow. If you would do it once across five accounts, lead a window.

• Same pass, a few accounts, right now

  The synchronizer. Nothing to write beforehand and nothing left behind.

• Same pass, many accounts, again next week

  A flow in RPA Plus, with variables and a schedule.

• Different work in each account

  Neither one. Open the profiles and work in them separately.