Feature request: label a profile visibly in the browser UI

[ingepanch13011]

A way to mark a running profile so users can tell which one they are looking at, from inside
the browser window itself. Either of these would do it, and both together would be better:

• Custom text somewhere in the browser chrome — the toolbar strip, next to the profile pill, or
  anywhere persistently visible that is not page content.
• A per-profile window and taskbar icon, settable at launch.

Why

Several profiles run at once on one desktop. They are identical browsers, with identical icons,
often on identical-looking pages. Telling them apart currently means clicking into a window and
inferring which account it is from what happens to be on screen, which is slow and easy to get
wrong — and getting it wrong means acting in the wrong account.

--window-name is the closest thing available and it does help, but only outside the browser: it
sets the window title, so profiles can be distinguished in the taskbar and in alt-tab. Once a window
is focused there is nothing on screen that says which profile it is. Windows also groups windows by
application, and every profile shares one icon, so even the taskbar view is weaker than it sounds.

A per-profile icon would fix the grouping problem, and a line of text in the chrome would fix the
focused-window problem. They solve different halves.

Shape

await launchPersistentContext(dir, {
  label: "profile 42 — some account",   // shown in the browser UI
  icon: "./icons/profile-42.png",       // window + taskbar icon
});

label is the more valuable of the two if only one is possible.

Notes

• Colour would be a useful addition to label — a background tint on the strip makes profiles
  distinguishable at a glance without reading, which matters more than the text itself when a dozen
  windows are open.
• The label only needs to be static for the lifetime of the window. Nothing here requires updating it
  at runtime, though that would be convenient.

[pim97]

Good request, and the split you draw — text fixes the focused window, icon fixes the grouping — is the right way to think about it. Both are feasible and neither is large. Three things came out of looking at it.

Part of this may already work. Windows taskbar grouping is keyed on the AppUserModelID, and the browser derives that from the profile path — so two profiles in different user data directories should already land in separate taskbar groups rather than being collapsed into one. If you are seeing them grouped together, that is worth reporting as its own bug, because it would mean something is overriding it. What is genuinely missing is the icon: every window draws the same one, so separate groups still look identical. Worth a quick check on your setup before we build anything, since it changes which half matters most to you.

--window-name is upstream Chromium, not something we added, which is why it behaves as you describe: it sets the window's user title and therefore only helps outside the window. Your read of it is accurate.

One constraint that shapes the design, and is worth stating before we write code. This is an anti-detect browser, and window.outerHeight - window.innerHeight is readable by any page — it is the height of the browser chrome. If a profile label added a strip, or grew the toolbar even slightly, every page could measure a chrome height that no ordinary Chrome produces. That would be a self-inflicted signal, and a worse trade than the usability problem it solves.

So the label has to live inside the existing toolbar height, as text and a background tint on chrome that is already there, never as an extra row. That is achievable — there is horizontal room — and the acceptance test is simple: outerHeight - innerHeight must be identical to a stock build, with the flag and without it. Mentioning it because it is the kind of constraint that is cheap to honour at design time and expensive to retrofit.

The icon has no such issue; window and taskbar icons are not visible to page content.

On priority: you are right that label is the more valuable half. I would add that colour is the part that scales. Text has to be read one window at a time; a tint is matched pre-attentively, so at a dozen windows the colour does most of the work. That argues for label and its colour shipping together rather than colour being a later addition.

Shape we would aim for, close to your proposal:

launchPersistentContext(dir, {
  label: "profile 42 — some account",
  labelColor: "#2d6cdf",
  icon: "./icons/profile-42.png",
});

Static for the lifetime of the window, as you say — nothing here needs runtime updates.

No date yet. We are chasing an intermittent stability issue first, since a profile label does not help much on a browser that occasionally goes down. Leaving this open and will report back here.