Halaman ini belum tersedia dalam bahasa Anda. Anda membaca teks bahasa Inggris.
Synchronizer
The window synchronizer
- 1
- Leading windows
- 40 ms
- The master's actions are collected every
- 100-600 ms
- A target window's pause before each action
- unambiguous
- Path to the clicked element
One window leads
The synchronizer sits in the manager under Automation. You mark one running profile as the master and one or more running profiles as targets.
You still do the work with your own hands, and the program only carries it into the other windows. You write nothing in advance, and nothing happens without you.
Clicks
The element you clicked with the left button, where the cursor landed in a field, and where inside the window you hit.
Typing
Every letter you typed, in a form field and in the box for the text of a post or message.
Paste
The text you pasted.
Scrolling
How far you scrolled with the wheel or a finger.
Keys
Enter, Tab, Backspace, Delete, Escape, the arrows, Home, End, Page Up, Page Down, keys pressed outside a field, and Cmd or Ctrl with A and Z.
Address changes
An address you typed, and a step back or forward. A target follows a link with its own click.

Your other windows stay untouched
The app takes your actions from inside the leading page itself, not by reading your mouse at the level of the operating system. A helper records them in its own separate world of the page: it has its own names and its own listeners, and the page's own code does not see them.
It listens only in the leading window, so an ordinary window stays untouched. The app collects what has piled up every 40 ms on both engines, and when you stop, the helper removes its listeners at once.
Only your input travels
What one action carries
Your click travels as more than a pixel. With it goes the element you hit, and where inside the window you clicked, kept as two fractions.
A field travels as letters, not as a finished value: the target types them itself, with keys, at its own pace. A scroll leaves as a distance, and a key by its name.
| Kind | What travels | What the target window does |
|---|---|---|
| Click | The element you hit, the point as fractions of the leading window and where the cursor landed in a field | Moves the mouse to a random point of the same element and presses with a hold, puts the cursor in the field at the same place; with no such element, presses at the same fractions of its own window |
| Typing | Letters typed into a form field or the box of a post | Types the same letters with the keys of its own layout, at its own pace |
| Paste | The pasted text | Pastes with the same key combination; in a password field it types letter by letter |
| Scroll | The distance you scrolled with the wheel or a finger | Turns the wheel the way the mouse of its own profile's system does, by the same distance |
| Key | The key name and the combination | Presses and releases the same key, Cmd or Ctrl by the system of its own profile |
| Navigation | A typed address, or a step back or forward | Opens the same address or takes the same step in its history; follows a link with its own click |
Replay aims at the element
Each target window looks for the same element first, turns the wheel until it is in view and moves the mouse to it, and only then clicks. This is the road that survives a window of another size or a page that has shifted under a banner.
If the element is not found, the fractions take over, resolved against that window's own width and height. A profile dressed as a phone sends a press as a touch and a scroll as a swipe, because a real phone sends no mouse events at all.
Before each action a target waits its own pause, from 100 to 600 ms, different for every window. Several windows doing the same thing in the same millisecond tie the profiles together on their own.
On ARMANOS Browser the visible tab leads
A profile often has several tabs: the ARMANOS start page, the address you asked for and the tabs left open last time. ARMANOS Browser reopens those when its On startup setting is Continue where you left off, as it is in a new profile. On ARMANOS Browser the leading tab is the one you are looking at, and the app learns which that is from the pages themselves.
- 1
The tab on screen leads
When the master has several tabs, the app asks them which one is on screen, and the first to answer leads. Otherwise a tab of the profile other than the start page leads.
- 2
Every target has its own answer
A target with no page to answer drops out before the session starts, and if none are left the start refuses and says so.
- 3
The leading window is ready
If the leading window cannot be prepared the session does not begin, because a half started session would look active and mirror nothing.
- 4
You see the count
The status bar shows how many windows are following and lowers the count as target windows close.
What travels after the start
The app picks the tabs once, when you press start, and keeps that choice for the master and for every target. Otherwise half your work would scatter into another tab.
A typed address and steps back or forward travel in the same queue as the actions, after them. A link or a submitted form the target repeats with its own click and does not load the same page a second time. Blank pages, error pages and developer addresses never reach the targets.
Every window on one grid
Mirroring is only useful if you can watch the result, so the manager can arrange every open window into a grid. It builds that grid on the display your cursor is on, inside its work area.
No cell smaller than 420 by 320
The app takes the square root of the window count rounded up for the columns and leaves six points between cells. If a cell would come out smaller than 420 by 320, it refuses and says why instead of laying out windows nobody can read.
Windows of both engines share that one grid, so they never land on top of each other. It skips a profile started without a window, and remembers the new place against that profile for 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 app uses on your machine. Below 420 by 320 per cell the answer is a refusal, not a grid.
By hand or by flow
The synchronizer is for work you are doing anyway, once, with your eyes on it: the same cookie banner in eight accounts, the same form, the same checkout to the same step.
A flow is for work you will do again. It costs more to write and far less to repeat.
A rule of thumb that holds up: more than twice, write a flow; once across five accounts, lead a window.
The same pass, a few accounts, now
The synchronizer. Nothing to write beforehand and nothing left behind.
The same pass, many accounts, again
A flow, with variables and a schedule.
Different work in each account
Neither one. Open the profiles and work in them separately.

Everything in the leading window travels
What this does not do
- Left button clicks, typing, pasted text, scrolling with the wheel or a finger, keys and main frame navigation travel. Dragging, hovering, right click menus, file choosing and actions inside an embedded frame do not.
- Replay is aimed, not verified. If a target shows another layout, another language or a logged out page, a click can land elsewhere or nowhere, and nothing reports it to you.
- A target types at its own pace and falls behind you: a long text it finishes after you have. A choice in a drop down list made with keys is always repeated, one made with the mouse only when that list is already focused in the target window. ARMANOS Browser opened without a window keeps its own clipboard, so there a paste is typed letter by letter.
- A target window fully covered by other windows counts as hidden to the system: it waits and repeats nothing until you can see it again. Before a session, lay the windows out with Arrange windows.
- One session at a time and one leading window. Starting another session stops the one that is running.
- Nothing is left on disk. A session cannot be exported, replayed later or turned into a flow.
How to check
Each claim below points at the file that implements it and the file that checks it.
- The master's actions really arrive in the target window, and do not arrive before you press start, and after Stop no recording listeners are left on the page
- apps/desktop/src/main/main.js · apps/desktop/test/синхронизатор-живьём.js
- Target windows get real clicks, letters, wheel turns and pastes, type at their own pace, wait their own pause and follow a link with their own click, and the clipboard comes back as it was
- apps/desktop/src/lib/синхронизатор-повтор.js · apps/desktop/test/синхронизатор-ведомые-настоящими-живьём.js
- A trap page on the master and on a target finds no scripted events, no new names and no calls of its own functions from the synchronizer beyond itself before the start
- apps/desktop/src/injected/агент-записи.js · apps/desktop/test/страница-ловушка-живьём.js
- On ARMANOS Browser the visible tab leads, and the tabs chosen at start are the ones used for the whole session
- apps/desktop/src/main/main.js · apps/desktop/test/синхронизатор-берёт-видимую-вкладку.js
- Capture on both engines relays only events a person actually generated, and records no faked click, input, key or scroll
- apps/desktop/src/injected/агент-записи.js · apps/desktop/test/синхронизатор-ядра-пишет-только-человека.js
- Windows of ARMANOS Browser really move into the grid, measured from inside the pages
- apps/desktop/src/main/main.js · apps/desktop/test/раскладка-живьём.js
- The grid is computed for both engines at once and refuses cells that are too small
- apps/desktop/src/main/main.js · apps/desktop/test/window-places.js
- On ARMANOS Browser the tabs of last time come back as its On startup setting says, and the start page and the profile address are not opened twice
- apps/desktop/src/lib/сеанс-форка.js · apps/desktop/test/вкладки-не-копятся-между-запусками.js
Questions
- How many profiles have to be open?
- At least two, and they have to be running already. With fewer the app says so and sends you to the profiles list, and on a plan that carries a single profile it sends you to the plans instead.
- What happens if the leading window closes?
- The session stops altogether. A target that disappears simply drops out of the set, and when the last one is gone the session ends by itself rather than mirroring into nothing.
- Can two sessions run at once?
- No. Starting a new session stops the previous one, so there is never a second leading window you have forgotten about.
- What is left behind after Stop?
- Nothing about the session is written to disk. The recording listeners on the leading window's page are removed as soon as you stop, on both engines, and starting again on the same page sets them once. On a Mac your clipboard comes back as it was after every paste, and if you copied something new while the targets were pasting, your new copy stays and the target types its text with keys.
- Do the windows have to be the same size?
- No. A click aims at the element first, and each target resolves the fallback fractions against its own width and height, not against the size of the leading window.
Try it on two profiles
Open two profiles, choose a master, tick the other one and start. Stop is one click away.