Password generator doesn't generate new password in the same session (opens in new tab)

If Window A->Site A needs to remain open but Window B->Site B is closed, and a new Private Window (opened using File > New Private Window) that we'll call Window C visits Site B the expectation is this is a 'clean' session.

But Window C->Site B then presents the same auto-generated password as was created in Window B->Site B even when using a different username.

ALL Private Windows have to be closed for the 'session' to be removed so that new passwords are generated.

In that case, if you are not paying attention all the new accounts will have the same password, which is a privacy issue.

It could be argued that if you don't logout/lock devices properly then you are unlikely to log out of sites, but the principal of security in depth requires accounting for partial use of best practise not all-or-nothing.

Also as described in the bug, you could accidentally create multiple accounts with the same password if you are creating or resetting accounts for multiple people (i.e. you are performing some sort of admin role in relation to local users of the site in question).

I can see the usability argument for the feature “behaving as designed” because often when a password cycle is required you have to enter it two or three times (once to set, once to confirm you didn't mistype that first one, then some password reset procedures don't leave you with a valid session so you need to immediately log in again with the new password), but it does strike me as one of those places where paranoia should trump usability.

You see, I'd just tried to create an account on a website with a slow network link. The website then failed to load. I wasn't sure if my account had been created or not. I always wait for the account creation step to succeed before I save a password, so I hadn't yet saved this random password.

I was a bit worried I'd have to go through a lengthy password reset process, on my slow internet link. Fortunately for me, going back to the account creation page simply popped up the same password, so I just hit the "Sign Up" button again, without worry of losing my password again.

    EDIT 2022-12-20: There are at least 3 cases where this is desirable within a short period of time:
    
        Filling password confirmation fields on the same page if we were not able to automatically do so.
        Filling the same password on the next page
        The password didn’t save on the change form so you need to fill it on the log in page.
    
    Bug 1551723 will give the user the option to choose a new password.

then the actual design is probably just badly thought through.

This very well could be the expected behavior to allow for the potential states of form entry and submission and the immense number of issues related to networking.

Whether this could be changed by a preference perhaps is definitely a possible avenue here, but if they want to have it this way so people are less likely to lose their password during sign-up then so be it.

Pick another password manager if you don't like it, but for the common user it's probably the best experience out of the box (even if I don't want it that way either)

    echo -n "$(diceware -d '-' -n 3)"$(( RANDOM % 10 )) | xsel -b

  openssl rand -base64 20

    pwgen 32 1  

(ignoring that they could get the same output by chance)

There's nothing fancy here. On password fields browsers have an auto-fill. Your method requires more effort compared to it.

If you read the page you would see it is functioning by design and the bug was closed 3 years ago. Not saying that is the proper behavior, but that would explain why you can reproduce it.

Wish the responder would have spend some time elaborating on "why" rather than just stating that it's "by design".