Bulk actions, groups and the recycle bin

Every card in the grid and every row in the table carries a checkbox. Ticking one adds that profile to a single selection set, and an action bar appears above the list with the count. The same select-all control sits in the table header and in the action bar, so the grid view is not stuck ticking cards one at a time.

Select all means everything your search and filters found, not the page in front of you. The list is paginated inside the window, but the filtered set is what the counter and the actions use. Filter down to one group, tick the box, and the action runs on all of them. The control even names the number it will take.

Ticking a box repaints only the selection state, never the whole list. That is why a double click still opens the editor: a full redraw would swap the card under your pointer between the first click and the second, and keyboard focus would be destroyed on every tick.

• Selection spans pages

  The set holds ids, so paging through the list never quietly drops what you picked.

• Clearing is scoped too

  Unticking select-all removes only what the current filter shows. Anything hidden by the filter stays selected.

• Clear

  One button empties the whole selection and hides the action bar.

The bar carries one primary button and six outline ones. They are deliberately narrow: each does one thing to every selected profile and then tells you the result. Nothing here edits a fingerprint, because a fingerprint belongs to one profile and copying one across a batch would make the batch look like one machine.

Move to group and assign proxy open a small window first, because they need a value. The rest act straight away, with a confirmation only where the action costs you something.

Fifty accounts signing in inside one minute, at even intervals, is itself a pattern. So the launch loop waits before every opening after the first, and the wait is random between 3 and 14 seconds. Random matters: an even seven seconds is just as readable a signature, and easier to compute. On fifty profiles that spreads the openings over several minutes.

The pause applies to launch only. Moving to a group, assigning a proxy, exporting and deleting are not things a website ever sees, so they run at full speed.

How many browsers can be open at once is decided by your machine, not by a number typed into the code. The app takes total memory, reserves 3 GB for the system, allows about 1 GB per browser, and clamps the result between 4 and 32. When memory cannot be read it falls back to 8. You can set your own number in the same range.

Hitting that ceiling is not a failure. The queue waits in five second steps for a window to close, for up to half an hour, marks the task as queued, and tells you once per batch that it is waiting. If nothing frees up in that time the batch stops and the report says how many opened.

1. 1

   Check for cancel

   Cancel is read between items. The profile already opening finishes; nothing after it is started.

2. 2

   Wait out the spread

   A fresh random 3 to 14 second pause, then cancel is checked again in case you changed your mind during it.

3. 3

   Ask to launch

   The answer is either a launched profile, a real error, or the flag that says there is no room right now.

4. 4

   Wait for room

   On the no-room flag the queue sleeps five seconds and asks again, up to thirty minutes, checking cancel after each sleep.

5. 5

   Record and move on

   The outcome is counted, the progress bar advances, and the first real error is kept for the report.

Every bulk run registers a task in the task centre: a title, a progress bar and a cancel button. Progress is written after each item, so a long run is visibly moving rather than apparently frozen.

The ending is one of four sentences, not a green tick. All done. Partial, with the count and the first real error. None done, with the error. Cancelled, with how far it got. A cancelled run that also had real failures says both, because "cancelled" alone would hide three profiles that never opened because their lock was busy.

Running out of room gets its own sentence and is not called an error, since nothing broke. But real errors are still named alongside it, so a busy profile or a dead proxy is not disguised as an unfinished queue.

While a run is going, every bulk button is disabled, not only Launch. A second press used to start a second queue over the same selection: two tasks, two contradictory results, and the careful spread between openings collapsing back into the burst it exists to prevent.

All succeeded

Launched 30 profiles.

Some failed

Launched 27 of 30 profiles, plus the first real reason.

Cancelled

Cancelled at 12 of 30, plus a second line if any of the 12 truly failed.

No room left

Opened 8 of 30: no room for more. Close a browser window and launch the rest.

Nothing to do

Every selected profile is already in that group, so nothing was changed.

Wording is shortened here. The app carries these strings in 22 languages, and the report picks the key by the outcome, never by matching English text.

A bulk action is one press that touches everything you selected, so the places where it could do harm silently are guarded one by one. Delete names the count in its confirmation. The assign-proxy window opens with every field cleared, including the key file path, because a value left over from last time would otherwise be written across the whole batch.

An empty proxy form means "remove the proxy", and since the window opens empty, that gets its own question naming the count and saying those profiles will then go online directly. The round robin checkbox does not survive closing the window, and the library picker does not remember your last choice, so the same button cannot clear proxies on one visit and silently reassign the previous address on the next.

Picking a saved proxy assigns the record itself, not a copy of its fields. The profile stays tied to the library entry, so its checks, exit country and IP rotation keep working. Typing one by hand is refused if it is half filled in, because a half configured proxy shows as configured on every profile and is then ignored at launch.

• Group already set

  If every selected profile is already in that group, you are told nothing changed instead of being shown a move that never happened.

• Round robin

  Profiles with an open browser are skipped, and the count of skipped ones is part of the report.

• Partial proxy assignment

  When fewer profiles were updated than you selected, that is a warning with both numbers, not a success.

• Tag in the dashboard

  A tag is added to the tags already there. Replacing would erase the labelling of a hundred profiles with nothing to restore it from.

A group is a real record kept on your computer: an id, a name, a colour, a sort order, and created and updated timestamps, written to a groups file with owner-only permissions. The shape mirrors the account's group model exactly, so one screen reads both and syncing them later is a merge rather than a rewrite.

They work signed out. Groups used to live only on the server, which turned the Groups screen into a permanent sign-in wall and left the move-to-group picker disabled everywhere, even though a group only ever described profiles sitting in a file on this machine.

The rules are small and deliberate. A name is trimmed to 60 characters, a computer holds up to 200 groups, and a duplicate name is refused because two identical entries in a picker is a trap rather than a convenience. Colours come from a fixed set of swatches, twelve in the app and seven in the dashboard, so a group can never be given a shade that vanishes into the dark theme.

Reordering is a hint for the eye and can never lose a group: unknown ids are ignored and anything missing is appended to the end. Clicking a group card filters the profile list to it. Deleting a group detaches its profiles instead of leaving them with a dangling id and no way back, and the app says how many followed the change.

Delete is soft. It stamps a deletion time, the profile leaves the list, and its data is untouched. The browser is closed first: deleting a running profile used to leave the row gone and the Chromium process alive, still browsing and still writing into a directory that no longer had an owner. Profiles in the bin do not count against your plan's profile quota.

The bin shows two lists merged into one. What you deleted on this computer, and what your account still holds. A profile deleted on another machine, or before a reinstall, appears with an "On your account" badge and can be restored from here. Restore re-checks the quota on the server, and a refusal aborts the local restore and is shown in your language rather than being swallowed under a success message.

Delete permanently has to mean it, because people sell a machine on the strength of that sentence. It erases the profile's browsing data on this disk first: the built-in engine's partition and the ARMANOS Browser user-data directory, with retries because Windows does not release file handles instantly. It also removes the profile's extension choices, schedules, launch notifications, statistics, pace counters, start page token, and the encrypted session file in your shared folder.

If any of that fails, you are told. The message says the record is gone but the cookies and saved logins may still be on this disk, names the reason, and asks you to close that profile's browser and delete again. Emptying the whole bin runs every item through the same machinery and gives the same honest count.

1. 1

   Delete

   The browser is closed, the deletion time is stamped, the row leaves the list, the data stays.

2. 2

   The bin lists it

   Local and account entries are merged and sorted newest first, with a badge on the ones that exist only in your account.

3. 3

   Restore

   The server re-checks your quota. A refusal stops the restore and is named; a profile known only to the account is adopted onto this computer.

4. 4

   Delete permanently

   Data is erased first, then the record. The message says whether the erase actually worked.

The browser dashboard has the same checkboxes, the same rule that select-all means everything the search found, and four actions: move to a folder, assign a proxy from your pool, add a tag, delete. Tags are the one thing you can set in bulk there and not in the app, where tags are edited on the profile itself.

There are no bulk endpoints on the server, and none are needed. The dashboard loops the single-profile calls, exactly as the app does, and shows the count as it goes. The first hard failure stops the loop on purpose: if your access ended or the connection dropped, the other forty nine calls will only repeat the same error while you watch a frozen page.

The report separates what changed from what was already right. A profile that already carries the tag is not touched at all and is counted as skipped, so "done, 50" cannot secretly mean that nothing changed on any of them. Profiles that disappear from the list are dropped from the selection, so the bar cannot claim twelve selected over nine living profiles.

Bulk launch is not there and is not planned for there, because the browser is opened by the program on your computer. The panel says that in plain words under the bar, so its absence reads as the shape of the product rather than a bug. The dashboard's recycle bin restores and purges one profile at a time, each with its own confirmation.

• Move to a folder

  The same folders you see in the app, chosen from a list.

• Assign a proxy

  Picked from your saved pool, by name and address.

• Add a tag

  Added to the existing tags, with the duplicates counted as skipped.

• Delete

  Two presses: the button, then a confirmation that names the count.