New browser beta dialog for changing an existing password got me locked out of a site.

Sequence of events:
-Watchtower alerts me to change my password at the Wegman's supermarket chain.
-I go to and click Sign In and 1Password correctly autofills my existing credential and I log in.
-I go to Change Password which page requires my existing password, which 1Password correctly autofills.
-I click into the first of two new-password fields. 1Password immediately offers a suggested new password which I accept.
-the bad part which happens quickly with no user action: the Wegman's page immediately accepts the new password and loads the site's main store page. Simultaneously, the 1Password browser window holding the new password vanishes, unsaved, never to be seen again.
-I now have the long, unmemorable password string saved at Wegman's but not known to me or 1Password. To change the password again, Wegman's requires the latest, unknown password. I have to make a support request to Wegman's to reset the password.

1Password Version: 7.7.810
Extension Version: 2.0.3
OS Version: Windows 10
Sync Type:
Referrer: forum-search:change password


  • ag_anaag_ana

    Team Member

    Hi @iWoodsman!

    1Password typically saves every password it generates. Do you see this latest password under the Password category in your 1Password app?

  • No the latest password was not saved and is not present in the database, only the previous password, that’s the nature of the malfunction: the password-change dialog box typically remains open waiting for the user to decide whether to accept the new password or to regenerate one again. This time the auto-refresh of the website appears to have caused the 1Password browser plugin window to spontaneously close without asking to save the new password, without saving it, and without any message. I thought maybe the dialog window had just lost focus and been sent behind another window, but it was truly gone.
    This may make no engineering sense, but it felt to me as if this Wegman’s website fully reloaded itself immediately after the password reset, as if I had clicked the reload button, (that is what it visually looked like) and Firefox interpreted this as a reason to close any secondary windows related or dependent on the now-missing stale version of the Wegman’s page. As if the 1Password extension had not actually crashed, but was forced to close and wasn’t aware of that. I don’t know if extensions are subprocesses controlled by the browser and can be killed, like a virtual machine can be dropped and nothing inside the VM can have awareness of that.

  • ag_yaronag_yaron

    Team Member

    Hey @iWoodsman ,
    Can you please check the generator's history?

    1. Click the 1Password icon on the top right corner of your browser and unlock it if needed.
    2. Click the big PLUS icon to reveal the menu.
    3. Select "Password Generator" (the first option in the list).
    4. Click the "Generator History" button at the bottom and see if you are able to locate the lost password there.

    It is quite unusual for a website to automatically send a change password form without the user's input, never heard of that before!
    Let us know if you found the password in the generator.

  • I checked that history, the new password WAS in the log yet is not saved in the 1Password record for the Wegman's site. I did the password change procedure again to make sure I was accurately reporting what happens and the behavior was identical, but as you suggest the site IS doing something unusual, automatically:
    I noticed that at the Wegman's login screen, the site is actively looking up my credential as soon as the user and password names are filled. I can see this because the site flashes me a warning about "invalid username or password" about a second after I stop typing my (old) password. There is a "Submit" button but this credential check is done before the user clicks it. Actually logging in requires a Submit.
    With the same wilingness to act on user input without user confirmation, Wegmans does definitely save the new password and immediately load the store page, and in the process the 1Password browser window closes. The new password is saved in Wegmans database, the new password appears in 1Password's Generator history, but the new password does not get copied into the Wegmans 1Password record (and I am never prompted to save it; there's no time before the 1Password browser dialog disappears.)
    So this appears to be a bad interaction with a rare case. Ideally, 1Password browser would have a way to detect and survive Wegmans action instead of dropping out. Maybe that's difficult if the browser dialog is somehow tied to the webpage, and if that page reloads, the browser has to close. OK, I just tested that at Wegmans password change page, and sure enough, while the 1Password suggestion dialog was open, I refreshed the page manually and the suggestion dialog disappeared in the refresh. I hope this helps and if needed I could probably do a screen capture video to prove I'm not insane.

  • ag_yaronag_yaron

    Team Member

    Hey @iWoodsman ,
    Thanks for the additional info.

    I'm glad to hear you were able to find your password in the generator history - it is an important failsafe that we implemented exactly for such unusual edge cases.

    The 1Password prompt to save/update a login entry/record is indeed a part of the webpage and therefor it will disappear if the page is refreshed or routed to a different page.
    In your last test you mentioned you manually refreshed the page which made the prompt disappear - why did you refresh the page manually? Did the website not refresh automatically this time as it did last time?

  • In my last test I manually refreshed the page before entering any text, before the Wegman's page had a chance to trigger its own reload, just to confirm that a reload would kill the 1Password prompt dialog. If it hadn't disappeared then, then maybe the disappearance was due to some other reason. But you've confirmed that if the current instance of the page leaves, the 1Password dialog gets cleared too.
    I don't remember seeing such a "helpful" page as this Wegman's page before. I think this is only 1Password's problem insofar as being a condition that threatens the integrity of your database. Given that a workaround is possibly very difficult for this rare condition, maybe the existence of the password-generator history could be highlighted? It is a very smart feature, yet I've used 1Password for years and while I knew that saved records had a list of previous passwords, I didn't know that there was a global list of previous attempts. Anyway, I feel like you've given me enough of a workaround to handle this problem as well as the more common situation where I myself somehow mis-type or mis-click the password change process. Thank you!

  • ag_yaronag_yaron

    Team Member

    Sorry for the delayed reply here @iWoodsman .
    Thanks for confirming and for the additional info.

    We've always had failsafes for instances where a new password is used but not saved. In our old classic extension, a new password item would have been created in your 1Password app, which you could then copy and put into your login item manually as the new password. Now, using 1Password in the browser, all new passwords you generate will reside in the generator history.

    If you encounter other websites like this one, and they are publicly accessible, feel free to send them our way so we can investigate them as edge cases and see if there's anything we can do to improve the experience here. :)

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file