Sort order of Password Manager is lost after making login changes/removals

NEW
Unassigned

Status

()

defect
P2
minor
16 years ago
23 days ago

People

(Reporter: mdver, Unassigned, Mentored)

Tracking

(Blocks 1 bug, {ux-trust})

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [passwords:management] [lang=js])

(Reporter)

Description

16 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624

When going through the password manager, I usually sort by user name.  Whenever
I delete a username/password set, the sort order resets to by site.

Reproducible: Always

Steps to Reproduce:
1.  Save a few usernames and passwords for various sites.
2.  Go to the password manager.
3.  Sort by username.
4.  Delete a username/password set.

Actual Results:  
The sort order reverts to site.

Expected Results:  
The sort order should have remained by username.

In case this is relavent, I had duplicates of the usernames for different sites.
Product: Browser → Seamonkey

Comment 1

14 years ago
This is still (or again?) an issue with SeaMonkey 1.1a:

Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9a1) Gecko/20050830
MultiZilla/1.8.1.0h SeaMonkey/1.1a

Lewis
Assignee: dveditz → nobody

Comment 2

11 years ago
Don't know why this was still unconfirmed. It is still an issue with current trunk.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008041601 SeaMonkey/2.0a1pre 
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
QA Contact: tpreston

Updated

9 years ago
Whiteboard: [obsoleted when bug 588421 lands]
Comment hidden (off-topic)

Comment 4

9 years ago
I don't use nightlies any more, I can tell you with the next beta, if you haven't tested yourself until then.

Comment 5

8 years ago
This is a general bug, not specific to SeaMonkey.
Component: Passwords & Permissions → Password Manager
Product: SeaMonkey → Toolkit
QA Contact: password.manager
Summary: Sort Oder of Password Manager from User Name Resets → Sort order of Password Manager is not preserved
Whiteboard: [CLOSEME 2011-02-01 INCO]

Updated

8 years ago
Duplicate of this bug: 318220
It’s still an issue in FF 18... and it’s even worse than originally described:

The lists ordering swaps (from ascending to descending) every time:
- a entry is deleted
- a entry is used by FF (i.e. you go to a page which is then auto-filled with one of the username/password
- a entry is updated by FF (i.e. one changed the password on the site, and FF asks whether to update it)
(In reply to Christoph Anton Mitterer from comment #7)
> It’s still an issue in FF 18... and it’s even worse than originally
> described:

This is a different issue and as you say a regression which has been started with Firefox 18.0. I filed bug 834000 yesterday to cover that.
Whiteboard: [passwords:management]
This is still an issue in 50.0a1 (2016-07-12).

If anyone wants to fix this bug, the code is at https://dxr.mozilla.org/mozilla-central/source/toolkit/components/passwordmgr/content

Bug 1197680 reports this happens from other storage changes so it's probably related to the passwordmgr-storage-changed observer.
Mentor: MattN+bmo
Keywords: ux-trust
Priority: -- → P3
Summary: Sort order of Password Manager is not preserved → Sort order of Password Manager is lost after making login changes/removals
Whiteboard: [passwords:management] → [passwords:management] [lang=js]

Updated

3 years ago
Severity: normal → minor

Updated

3 years ago
Blocks: 1317170
See Also: → 234973

Comment 11

2 years ago
(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #9)
> This is still an issue in 50.0a1 (2016-07-12).
> 
> If anyone wants to fix this bug, the code is at
> https://dxr.mozilla.org/mozilla-central/source/toolkit/components/
> passwordmgr/content
> 
> Bug 1197680 reports this happens from other storage changes so it's probably
> related to the passwordmgr-storage-changed observer.

I think it's related to the function 'tree.treeBoxObject.ensureRowIsVisible(nextSelection);' since all of the other places where it's called also have no effect.

Looking for the function definition I found https://dxr.mozilla.org/mozilla-central/source/obj-x86_64-pc-linux-gnu/dom/bindings/TreeBoxObjectBinding.cpp#614

I can't figure out what the function is doing.

Comment 12

2 years ago
is this solved or can be closed as incomplete status.

Comment 13

2 years ago
(In reply to Ahmed Almutairi from comment #12)
> is this solved or can be closed as incomplete status.

The work is being done in https://bugzilla.mozilla.org/show_bug.cgi?id=234973. I am waiting for a review. You can pull the patch from that bug and test it out though.

Comment 14

2 years ago
Can't reproduce after the fix from https://hg.mozilla.org/mozilla-central/rev/a3a3e0d6518f. Can somebody else try and confirm?
bug 1423375 claims it's still an issue… maybe see the STR there?
Flags: needinfo?(hashhar_dev)

Comment 17

a year ago
For quick reference here my text from 1423375 to reproduce with FF57 if it is the same as here:

Steps to reproduce:

- open the settings
- open the password manager
- show the passwords
- enter the master password
- sort by Website
- delete the first entry by pressing Del key


Actual results:

the sort order was still displayed with the little arrow in the table header, yet the order was not like before the deletion of the entry


Expected results:

order should not be affected, just the entry deleted
Flags: needinfo?(hashhar_dev)
You need to log in before you can comment on or make changes to this bug.