Closed Bug 210461 Opened 21 years ago Closed 17 years ago

In Cookie Manager, 'Remove Cookie'/'Remove Site' reset the display to the top of the list

Categories

(Core :: Networking: Cookies, defect)

x86
Windows 2000
defect
Not set
trivial

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: ken, Unassigned)

References

Details

(Keywords: polish, regression)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030612
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030612

In the Cookie Manager, when I "Remove Site" it reset the display to the top of
the page.

It should leave the list box at the position it was just at, so I can see the
next site alphabetically.  (In this case, I wanted to allow cookies at
passport.com and passport.net, which were right next to each other.  After I
removed the first "site cannot set cookies" it jumped to the top of the list, so
I had to scroll down in order to remove the second.)

Reproducible: Always

Steps to Reproduce:
1. Scroll down.
2. "Remove Site" for one of the cookie settings.
3. List box will scroll to the top.

Actual Results:  
List box scrolled to the top.

Expected Results:  
List box should have stayed where it was.
In the other pane in the cookie manager, "stored cookies", removing a cookie
works as one would expect: the selection moves on to the next cookie so it's
easy to remove a bunch of cookies from the same or similarly-named site. Perhaps
the code from there could be reused in the "sites" pane?

The bug is still present in 1.5: 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
I just tried to remove cookies and the behaviour was the same - jump to top.
I have 'Don't allow sites that set removed cookies to set future cookies' set on.
The selection moves to next cookie, but I have to scroll there again.

I confirm that when I removed one cookie site, selection moves to next site, but
view is moved to the top, AND sort is changed to Site (I had sites sorted by Status)
Re comment 0:

I'm not using the "Cookie Sites" pane, so I won't comment on it.

But I'll comment on the "Stored Cookies" pane:


Re comment 1:

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007] (W98SE)

I confirm that v1.5 works as intended: no unwanted scroll :-)


Re comment 2:

{ [Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6a) Gecko/20031030]
(BuildId=2003110115, bug 224340#c19) (W98SE) }
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6b) Gecko/20031208] (W98SE)

I confirm that v1.6a and v1.6b 'Remove Cookie' reset the display to the top of
the list (unwanted),
while the selection/focus "remains" on the expected row (correct).

Updating:
*(S) normal -> trivial
+(K) regression (during the v1.6a cycle)
+(F) blocking1.6=?
*(S) unconfirmed -> new
Severity: normal → trivial
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.6?
Keywords: regression
Summary: In the Cookie Manager, when I "Remove Site" it reset the display to the top of the page → In Cookie Manager, 'Remove Cookie'/'Remove Site' reset the display to the top of the list
Keywords: polish
It's only partly a regression: deleting an entry in the "cookie sites" pane was
resetting the display even in 1.5 (and probably earlier).
probably wouldn't hold the release for this bug but we'd consider approving a
reviewed patch if it happens in time. 
Flags: blocking1.6? → blocking1.6-
Re comment 4:

Agreed,
according to comments so far,
I would suggest to fix the "Stored" regression first,
then see about the "Site" issue.
Flags: blocking1.6- → blocking1.6?
mid-air collision ... resetting 'asa: blocking1.6-' :-<
Flags: blocking1.6? → blocking1.6-
isn't this a dupe of bug 206939? Seems so to me...
*** Bug 221370 has been marked as a duplicate of this bug. ***
Depends on: 221185
*** Bug 225891 has been marked as a duplicate of this bug. ***
worksforme with linux trunk 20030130.  is this still a problem with windows?
(In reply to comment #11)
> worksforme with linux trunk 20030130.  is this still a problem with windows?

I assume you mean trunk 20040130?
ya, 2004.
in windows it works OK :)
Using Windows NT 5.1; en-US; rv:1.7a) Gecko/20040125 ZIP install, I still see it.

As a side note, I also see this in the Password Manager. Same bug?
Using Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040218 ZIP install,
this appears fixed (but not in the password manager. I guess that's a searate bug).
(In reply to comment #15)
> As a side note, I also see this in the Password Manager. Same bug?

The cause might be quite similar;
the P.M. bug is bug 234973.
-> default owner
Assignee: darin → nobody
wfm in trunk firefox & seamonkey.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.