1480175 - No longer able to filter/delete cookies and data on a per-container basis

Status: NEW

(Firefox :: Settings UI, defect, P3)

Description

[echosa]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180704003137

Steps to reproduce:

I recently reinstalled the browser and all my add-ons, including Multi-Account Containers. Before installing Multi-Account Containers, I visited some sites that I then containerized after installing the extension. I then went to my settings to delete the cookies and data still leftover in the default container for those sites, only to find that I'm unable to do so. It seems as though that functionality has been removed, though I certainly hope not and that I'm just missing something!


Actual results:

The Settings -> Privacy and Security -> Cookies and Site Data -> Manage Data option does not show which cookies/data are tied to which containers, which would allow me to only delete cookies for domain from specific containers.


Expected results:

I should be able to delete cookies and data from specific containers, like I used to be able to do in previous versions of the new Firefox (post-Quantum). I'm not sure when this change happened. If memory servers, cookies and other site data used to have two different areas in settings where you could clear them individually, right? Perhaps when those were merged into a single "cookies and site data" settings area, the ability to pick-and-choose what to delete was lost.

Comment 1

[u554753]

Hi echosa,

Can you elaborate on your Steps to reproduce? What add-ons are you using and what sites did you visit?

You could also help by sending us info in your about:support so we can accurately attempt to recreate this issue. Thanks!

Comment 2

[echosa]

I'm happy to provide more info! I was able to get my hands on an older version of Firefox so I have screenshots, too! I don't think you'll need my full about:support. If my screenshots are enough, then I'll do another message with about:support. It's a LOT of text apparently! (Using the "copy text to clipboard" button.)

So, here's the issue. On previous versions of Firefox (these screenshots are from 57), we were able to see which container cookies belonged to like this:

- Go to Settings -> Privacy and Security, and click "remove individual cookies". Screenshot: https://cl.ly/110N26440U3Q

- From that screen, pick a cookie and you can see which container it belongs to. Screenshot: https://cl.ly/1N0d3e192L0B

This made it easy to delete cookies for sites from specific containers while leaving the cookies for that site in other containers untouched.

In the current version of Firefox, 61.0.1, I don't see a way to do this. Am I just missing where individual containers' individual cookies can be managed?

Comment 3

[Valentin Gosu [:valentin] (he/him)]

Thanks for reporting this bug.
Would you mind helping us by tracking down which commit introduced this problem with mozregression? https://mozilla.github.io/mozregression/quickstart.html
That would be very helpful.

Comment 4

[echosa]

Sure! Here's the results:

11:37.89 INFO: Last good revision: c7ffbaaf8c2e3ac13577da6413aa14fcf73ee151
11:37.89 INFO: First bad revision: 36be9b83bcc9928cd06ebdd3402939e152582fff
11:37.89 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=c7ffbaaf8c2e3ac13577da6413aa14fcf73ee151&tochange=36be9b83bcc9928cd06ebdd3402939e152582fff

Comment 5

[Johann Hofmann [:johannh]]

I agree we could improve the story around this, but it's not a high priority.

Comment 6

[Ben]

(In reply to Johann Hofmann [:johannh] from comment #5)
> I agree we could improve the story around this, but it's not a high priority.

What does, "improve the story around *this*," even mean?  Like better "political spin?"
This may be a deal breaker for many users.

No, continuing to lose important function / options and not fix bugs (that dwindling remaining users care about) in a browser that millions of people voted against with their feet (fingers?), isn't a "high priority."

Comment 7

[Johann Hofmann [:johannh]]

(In reply to Ben from comment #6)
> (In reply to Johann Hofmann [:johannh] from comment #5)
> > I agree we could improve the story around this, but it's not a high priority.
> 
> What does, "improve the story around *this*," even mean?  Like better
> "political spin?"
> This may be a deal breaker for many users.
> 
> No, continuing to lose important function / options and not fix bugs (that
> dwindling remaining users care about) in a browser that millions of people
> voted against with their feet (fingers?), isn't a "high priority."

By "story" I meant the user experience. I would like to remind you of point 2 of the Bugzilla Etiquette:

> No obligation. "Open Source" is not the same as "the developers must do my bidding." Everyone here wants to help, but no one else has any obligation to fix the bugs you want fixed. Therefore, you should not act as if you expect someone to fix a bug by a particular date or release. Aggressive or repeated demands will not be received well and will almost certainly diminish the impact of and interest in your suggestions.

It's hard to perceive from the outside, but a browser is a massive project with tons of different components and all of them are important to someone. Just because this is the highest priority to you doesn't mean it is for everyone else. Believe me that I would love to work on this, but understand that there are more urgent tasks that need my attention.

Comment 8

[Liz Henry (:lizzard) (relman/hg->git project)]

Marking fix-optional for 64. We could still take a patch for 65, and if it's verified and doesn't seem risky, could still take fixes for 64 as well.

Comment 9

[Daniel Harper]

Is there a chance this might be looked at again?
Or maybe introduce a feature where you can restrict what domains can install cookies into a container.