Open Bug 1764265 Opened 3 years ago Updated 2 years ago

Password is not updated when changing password in facebook

Categories

(Toolkit :: Password Manager: Site Compatibility, defect, P2)

Firefox 99
defect

Tracking

()

People

(Reporter: gladstone70, Unassigned)

References

()

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:99.0) Gecko/20100101 Firefox/99.0

Steps to reproduce:

I got a mail in Gmail with a link to a contribution of a friend on Facebook. I clicked on the link and loged in to Facebook.
Later, I wanted to log in to Facebook on the website directly. A message said: You are using an old password. Then I remembered that I had changed my password for Facebook yesterday. The password was not changed in the Firefox password manager.

Actual results:

Log in to Facebook from Gmail with old password.
Direct log in to Facebook works fine (with warning of old password).

Expected results:

It shouldn´t be possible to enter a website with an old password.
The Firefox password manager should have saved my new password yesterday.

The Bugbug bot thinks this bug should belong to the 'Toolkit::Password Manager' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Password Manager
Product: Firefox → Toolkit
Component: Password Manager → Password Manager: Site Compatibility
Summary: I loged in to Facebook with an old password → Password is not updated when changing password in facebook
Severity: -- → S3
Priority: -- → P2

Hi Steph,
I just tried to reproduce this and indeed there seems to be something wrong with the way passwords are saved.

Here is my test scenario:

  • Go to https://facebook.com and login with old password.
  • Prompt is shown to save login. ( Clicked save )
  • Old password page shows up.
  • Enter the correct password.
  • Prompt is shown to save login. ( Clicked save )
  • Checked logins in the about:logins page and there seems to be two entries. One with both the email and old password. The other with no username and the new password.

I am tackling this and will open a patch soon.

Assignee: nobody → imani
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

QUICK UPDATE !
This behavior is most likely due to the fact that the "old password" screen doesn't render the username/email as an input, but rather as text. Therefore the login chosen is the one without a username. This inconsistent behavior also happens when logging in from https://facebook.com/login rather than the index page.

I have also seen odd occasions where passwords (or user-ids certainly), have not been saved, so hopefully a patch will fix these sometimes difficult to reproduce scenarios. I see that BUG 1765381 for "Show Save Login only when user has interacted with the page" was put into FF102 (Nightly?) so hopefully that will not be too aggressive and negating or conflict with your patch in any way?

Flags: needinfo?(imani)

(In reply to Tony Davis from comment #4)

I have also seen odd occasions where passwords (or user-ids certainly), have not been saved, so hopefully a patch will fix these sometimes difficult to reproduce scenarios. I see that BUG 1765381 for "Show Save Login only when user has interacted with the page" was put into FF102 (Nightly?) so hopefully that will not be too aggressive and negating or conflict with your patch in any way?

No I don't think this is related.

Flags: needinfo?(imani)

Here is an update after I did some digging.

The heuristic we use is actually behaving as expected. After attempting to log in using an old password, the user is redirected to a login form with only one password input and the email/username is rendered as text.

Since we have no existing way (that I know of) of handling this, my initial thought was to use recipes for this :

  • add a selector that will be used to select text in case a username input is not available.
  • extract username/email using the selector and use that as a username. ( This will work for both the case of adding a new and updating a login).

Although this approach seems easy, there is one problem with using CSS selectors. AFAIK it is impossible to select text nodes directly. This will result in the process described above being not 100% reliable. For instance, in the case of facebook's old password login page this is the dom structure:

<div id="...">
     .....
    <div class="....">
        email@example.com
        <span> other text </span>
        <a id=""> some text </a>
    </div>
</div>

There is no way to select email@example.com using a CSS selector. Hence the approach described will require some hacking.

As discussed with Serg, it might be worth waiting for https://bugzilla.mozilla.org/show_bug.cgi?id=1771806, where a new way of capturing user input will be introduced, which will change the way we look at input and values.

Status: ASSIGNED → NEW
Assignee: imani → nobody
You need to log in before you can comment on or make changes to this bug.