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

Status: RESOLVED DUPLICATE of bug 1317170

(Toolkit :: Password Manager, defect, P2)

Description

[Marc DVer]

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.

Comment 1

[Lewis Rosenthal]

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

Comment 2

[Peter Weilbacher]

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 

Comment 3

[Philip Chee]

Peter, does this still happen with SeaMonkey 2.1b2pre?

Comment 4

[Peter Weilbacher]

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

[Frankie]

This is a general bug, not specific to SeaMonkey.

Comment 7

[Christoph Anton Mitterer]

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)

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(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.

Comment 9

[Matthew N. [:MattN]]

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.

Comment 11

[Ashhar Hasan]

(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

[Ahmed Almutairi]

is this solved or can be closed as incomplete status.

Comment 13

[Ashhar Hasan]

(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

[Ashhar Hasan]

Can't reproduce after the fix from https://hg.mozilla.org/mozilla-central/rev/a3a3e0d6518f. Can somebody else try and confirm?

Comment 16

[Matthew N. [:MattN]]

bug 1423375 claims it's still an issue… maybe see the STR there?

Comment 17

[Björn Kautler]

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

Comment 18

[Matthew N. [:MattN]]

Not going to fix this in m-c anymore since we now use about:logins but TB can fix it in its fork.

Comment 19

[Adam Katz]

It's worth noting that this is still a problem in Firefox 68 and the aforementioned about:logins page doesn't work because it'll be introduced in Firefox 70.

(It is disappointing that the page either hangs or is blank rather than giving the "Invalid URL" display that you'd get from actual invalid about:… links such as about:invalid. I also miss the base about: screen, which now becomes a web query.)

Presumably this bug will be reopened or else a new bug will be logged in the event that the new about:logins interface also suffers this problem.

Comment 20

[Matthew N. [:MattN]]

(In reply to Adam Katz from comment #19)

It's worth noting that this is still a problem in Firefox 68 and the aforementioned about:logins page doesn't work because it'll be introduced in Firefox 70.

Firefox 69 is the current release so you won't have to wait too much longer…

(It is disappointing that the page either hangs or is blank rather than giving the "Invalid URL" display that you'd get from actual invalid about:… links such as about:invalid. I also miss the base about: screen, which now becomes a web query.)

Yeah, I agree but this won't be a problem for many more weeks.

Presumably this bug will be reopened or else a new bug will be logged in the event that the new about:logins interface also suffers this problem.

I wouldn't have closed it if the new page had the same problem. AFAICT it doesn't.