Operate Multiple Webpages Concurrently
Use Parallel List Loop to operate multiple webpages concurrently. The list may contain any item type, and one parallel iteration is started for each item.
- Download and import parallel-hover-click.qya (right-click and select Save link as) to view the sample workflow.
Example
-
Open five webpages in sequence, then enter messages and click Submit on all of them concurrently.
-
Log in to different accounts in multiple BitBrowser or AdsPower windows. Configuration is similar to List Loop, but List Loop runs iterations sequentially while Parallel List Loop runs them concurrently.
| Normal List Loop execution order: | Parallel List Loop execution order: | ||||||||
|
|
Within each parallel task, commands still run sequentially. For example, a task opens the webpage, enters the account, enters the password, and clicks Log In in that order.
Parallel tasks run independently. For example, task B may be entering a password while task A is only beginning to enter an account name and task C is opening its webpage. Task B may finish first in one run, while task A or C may finish first the next time.
Wait for UI lock
A lock ensures that only one parallel task at a time can use a protected shared resource.
Imagine several factory assembly lines that all share one welding machine. A line may use the machine immediately when it is free, but must wait if another line is using it. A UI lock applies the same rule to shared resources such as the mouse and keyboard.
Without a lock, one task could interrupt another halfway through a drag. Likewise, if one task presses Ctrl as part of Ctrl+C and another task sends Q before C is pressed, the active window could receive Ctrl+Q and close unexpectedly.
Using a lock has three stages: acquire the lock, hold it while accessing the shared resource, and release it afterward.
Runavelo's built-in input, click, and mouse-drag commands acquire the UI lock automatically. Other tasks that need the same UI resource wait until the current operation finishes.
Although built-in UI commands acquire a lock automatically, unexpected behavior may still occur if the parallel workflow is not structured correctly.
For example, the following workflow opens multiple webpages concurrently, recognizes a slider CAPTCHA, and drags the slider. Other tasks cannot drag the mouse while task 1 is dragging, but task 2 may bring another webpage to the foreground immediately before task 1 begins. Task 1 would then drag on task 2's webpage, leaving both workflows in an invalid state.
Activating the correct webpage before dragging is not sufficient by itself: another task may bring its webpage to the foreground between the activation and the drag.
Use Wait for UI Lock to protect a sequence that must remain atomic. Place Activate Webpage and the related drag command inside it. While one task executes that block, other tasks cannot run UI commands such as click, input, or mouse drag. Before a task reaches Wait for UI Lock, other tasks may still click, enter text, or drag the mouse. When the task reaches Wait for UI Lock, it attempts to acquire the lock. If the lock is available, the task acquires it and executes the indented commands. If another task holds the lock, the current task pauses until the lock is released. After all commands nested under Wait for UI Lock finish, the task releases the lock automatically.
Do not wrap the entire parallel iteration in Wait for UI Lock, because that serializes all work. Protect only the sequence that must use the shared UI resource without interruption.
- Prefer silent input and silent click when the target element supports them. They avoid competing for the physical mouse and keyboard and usually run faster.
- Install the BitBrowser/AdsPower extension first. See Install the BitBrowser/AdsPower Extension.
- Runavelo extension version 2.0.0 or later is required.