In that case, if you are not paying attention all the new accounts will have the same password, which is a privacy issue.
On another note, admin shouldn't be sending entering other peoples passwords anymore, they should be sending invites links that let's the user insert their own.
Unfortunately the people who have to use software are often not the people responsible choosing it!
> where the admin knowing their password is a requirement
For creating fresh accounts this is less of an issue than once the account has access to real data that has already been entered, so all the admin can get by knowing the password at this point is the information they already had to create the profile and account with. While still not good design it is at least mitigated somewhat in practise. The main issue this behaviour-as-designed introduces is one new user being able to guess another new user's password. The danger this poses can be reduced by forcing the user to choose a new password on first login, before any information is entered, but it still isn't good design to even need this mitigation. If the software is badly arranged enough that the admin knows the password instead of it being generated and sent to the target user without the admin being any the wiser, then it may be that the “force change on first login” option is missing too.
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.
I think it would make sense to create a "regenerate" button or something like that.
True, but:
1. People are aware of that, it is an expected threat vector so at least a little less likely to be an issue. The behaviour of the FF password generator function is unexpected (to many) so is a hidden potential problem.
2. Good password managers have the option to auto-logout after inactivity which can mitigate an attack if not performed quickly.
3. Other similar attack vectors existing does not mean this one shouldn't be considered for closure, or if not closing by changing the behaviour perhaps instead adding a warning.