Open Bug 1715736 Opened 3 years ago Updated 2 years ago

New generated password for a site opened in container tab is not auto-saved if it previously had a password generated and auto-saved in any kind of tab

Categories

(Toolkit :: Password Manager, defect, P2)

Desktop
All
defect

Tracking

()

Tracking Status
firefox89 --- affected
firefox90 --- affected
firefox91 --- affected

People

(Reporter: tbabos, Unassigned)

Details

Attachments

(1 file)

Affected Versions:
All latest Firefox Versions

Tested on:
MacOS 10.15

Steps to reproduce:

  1. Open any registration form in a normal tab (ex: facebook)
  2. Open the same registration form in a container tab
  3. Generate a password in the normal tab (observe the generates password and ensure it is auto-saved)
  4. Generate a password in the container tab (observe the generated password)

Expected Result:
The generated password in the container tab should be auto-saved given it is different from the one in the normal tab. The UI should also notify the user about the auto-save aspect, as in the normal tab.

Actual Result:
The new password is generated in the container tab but it is not auto-saved. The "Firefox will save this password for this website" string is also not displayed for the password generation option. Recording: https://streamable.com/05rnwu

Regression-range:
Not a recent regression, can be reproduced back to 76 as well.

Notes:
This can be also reproduced with reversed steps, generate password in a container tab first and then in normal tab.
This issue does not affect the auto-save in the container tab aspect if a different site is opened. (applies only for same site scenario)

:timea can you confirm this behavior is only reproduceable for container tabs? I think if we'll see the same thing with a normal second tab, and this is expected behavior? I can see how a user might expect something different from a container, but I'm not sure what exactly.

Flags: needinfo?(timea.babos)
Priority: -- → P3
Priority: P3 → --

With normal tabs it is not really the same, we don't auto-save the password from the second tab because it is the same one that we generated in the first tab. This is the expected behavior.

However, for container tabs, we do generate a new password (different from the one from the first tab) but we don't auto-save it. As a saving anchor, we do have dismissed/save doorhangers so there is a low chance that the user could lose his credentials for the new account in this scenario where we don't auto-save the generated password.

I personally expected the auto-save function to work for a generated password in a container tab if that site already has a generated password saved but different from the newly generated one.
Normally, we have only 1 generated password/site/session, there have been user reports asking to generate a new one each time the option is selected. Container tabs can be used to achieve that (instead of restarting the browser) but we do lack the auto-save functionality for them or it is indeed a bug. (I repeat, only if we try to do this for the site that already has a generated password created in the normal or any other type of container tab).

I also checked if a new password is generated when I open a site in all the container types (personal, work, banking, shopping), and yes we have a new one generated for each container, but again we only auto-save the very first one generated (ex: in the first opened container - personal).

Flags: needinfo?(timea.babos)
Summary: New generated password for a site opened in container tab is not auto-saved if it previously had a password generated and auto-saved in a normal tab (and vice-versa) → New generated password for a site opened in container tab is not auto-saved if it previously had a password generated and auto-saved in any kind of tab

Thanks for raising this.
I'm proposing P2 as while containers don't see a huge amount of use, when used there is the potential to lose a password we just generated here so it shouldn't get lost in the P3 backlog.

Priority: -- → P2
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: