Choose “Save account only” when you want to select an existing login space later. Choose “Save account + site” when you also want a shortcut that opens a particular address in that space. Both options refer to the space already in use; saving a destination is a separate choice.
The request began with an easy way to add a newly logged-in account to the list, then added a separate option for opening its site. In the development candidate and test records, the difference extends beyond a form field: it determines which tab can be reused and what a later registration updates.
The next button should reflect the registration choice
The form asks for a recognizable account label and a registration mode. It asks for a destination only when a site is included. Requiring an address from someone who only wants to keep the account in the list adds a field without a purpose.
The list uses different action labels, too. “Use account” selects a login space; “Open site” opens a saved address in that space. Sharing a registration form does not make those actions interchangeable.
- Save account only → “Use account.” Select an existing user tab in that login space within the current project, without navigating it to a particular site.
- Save account + site → “Open site.” Find a user tab in the current project with both the saved address and the saved login space. Create a tab if there is no match.
- If an account-only entry has no reusable user tab, open a new home tab in that space. Do not guess which site the person last intended to visit.
The saved entry refers to an existing space
The implementation adds a label, site identity, registration mode and optional destination to an existing profile. An ordinary space that was previously unassigned keeps its identifier when it is added to the list. Registration does not replace it with a fresh space or copy passwords and cookies into another one.
A label such as “Work” is a name chosen by a person. Switching the site's account inside the same space and adding another label does not preserve the previous authentication separately. Keeping independent accounts on the same site requires signing in within separate login spaces. The related article below explains the distinction between a saved label and current authentication.
Registering again changes the existing entry
Registering the same site origin again within the same login space retains the existing entry identifier and updates the label and mode. Changing from site registration to account-only removes the destination. Entries in different login spaces remain separate, even if their labels match.
For a newly registered site, the suggested destination is the origin's root address. An origin identifies the scheme, host and port. The default address excludes the current page's query and fragment. A manually entered address is checked for embedded credentials, queries, fragments and known authentication paths, and must match the origin or a service recognized by the implementation. These are the rules in the code I read, rather than a guarantee that it identifies every site's authentication URL.
A matching address is only part of choosing a tab
Opening a saved site looks for a tab belonging to both the current project and the saved login space. It reuses only a user tab with the matching saved address, excluding tabs owned by other tasks. A matching site in another project does not qualify. Using an account-only entry does not require an address match, so a user tab in the same space can be selected.
Registration also rechecks the current tab, profile, project and site origin. The open action checks for active, waiting or paused work and uncertain outcomes, among other conditions. After capturing drafts, it checks that the context has not changed. When those conditions prevent opening, it stops for another check rather than selecting a nearby tab that looks suitable.
Report internal saving and folder updates separately
This development candidate saves the internal registration list before updating metadata in an existing separate login folder. If only the folder update fails, the message says that the internal registration was saved but the separate folder update failed. Registering an entry does not create a fresh copy of the session folder.
When only internal saving succeeds, name the saved store and the folder that failed to update. That lets the user judge whether to repeat registration or check only the folder update. This is an interpretation of the retry design; the records do not establish automatic recovery from every disk error.
A working button does not establish successful authentication
One recorded defect left the current tab’s account mode unassigned after an unassigned space was registered. Adding a label to the list had not updated the tab’s account state. The correction connected both states, something a success-message check alone could miss.
Existing unit tests cover stable identifiers on repeated registration, destination removal on a mode change, rejection of changed context and tab reuse conditions. Historical packaged-app review records also describe choosing both modes, opening a saved site again, retaining project selections after restart and using the form in a small window. The session markers were synthetic; these tests did not establish authentication with a real service. For this article I compared code with those records. I did not run the app, switch accounts, sign in again or perform a fresh screen review. The original record also distinguishes a verified development candidate from an operating-app rollout still awaiting a safe opportunity.
Specify what happens after registration
As an illustrative example, consider a work tool that manages both a “Work account” and a “Dashboard opened with that account.” Decide first whether account-only selection should leave the page in place and which project's tab a shortcut may use. Those decisions determine what needs saving. Check that renaming, changing modes and registering again keep the same promises.
A useful checklist records whether selection navigates, what repeated registration changes, which project's tabs may be reused and what the message says when only part of the save completes. These are the conditions examined in this article's code and test records. The related development notes cover session sharing and authentication labels.