Name compartment after shared origin instead of first URL

RESOLVED WORKSFORME

Status

()

defect
RESOLVED WORKSFORME
8 years ago
7 years ago

People

(Reporter: GPHemsley, Unassigned)

Tracking

({privacy})

Firefox Tracking Flags

(Not tracked)

Details

Compartments are apparently named after the first URL to use them, despite being representative of all tabs with the same origin.

It seems to me that the compartments should instead be named after just the shared origin, and not any particular URL. (This is particularly important when the tab for the first URL is closed, while other tabs in the same origin are not. It makes it look like there zombie compartments.)
The advantage of the current approach is that you see strictly more information in about:memory.  This is sometimes important.  For example, in bug 664067 there were numerous facebook.com compartments, and it was very helpful to see the differences -- that made it clear some were for "like" buttons, some were for "send" buttons, others were for other things.

The disadvantage is that sometimes it's misleading, as in your case -- a compartment created for BMO bug 123456, for example, will persist as long as other bugs are open in other tabs, even once bug 123456 is closed.

One suggestion made was to only show the origin by default, but if there are multiple compartments with the same origin, then show the full URL.  It's not clear to me that's a big improvement, but I also don't have any other suggestions.
What if we visually highlighted the origin, much as we highlight the domain in the address bar?  Maybe that, plus an improved tooltip (*) would make this clear enough.

(*) I'm going to come up with a compelling use-case for adding tooltips for implied tree nodes one of these days.  You just wait...
(In reply to comment #1)
> The advantage of the current approach is that you see strictly more
> information in about:memory.  This is sometimes important.  For example, in
> bug 664067 there were numerous facebook.com compartments, and it was very
> helpful to see the differences -- that made it clear some were for "like"
> buttons, some were for "send" buttons, others were for other things.
> 
> The disadvantage is that sometimes it's misleading, as in your case -- a
> compartment created for BMO bug 123456, for example, will persist as long as
> other bugs are open in other tabs, even once bug 123456 is closed.
> 
> One suggestion made was to only show the origin by default, but if there are
> multiple compartments with the same origin, then show the full URL.  It's
> not clear to me that's a big improvement, but I also don't have any other
> suggestions.

I'm sure there are a thousand things that I don't understand about this, but why would there be multiple compartments if each compartment is supposedly created for a single shared origin?

It seems to me (logically speaking on the surface, without any knowledge of the behind-the-scenes operations) that you would either have one compartment per shared origin (which would be named after the origin) or one compartment per URL (which would be named after the URL). What are the reasons for having the two coexist?

But even if you needed to have the two coexist, I'm sure there are specific use cases for each, so why not come up with some way to format the names differently, so that you can tell the difference between a per-origin compartment and a per-URL compartment?
(In reply to comment #2)
> What if we visually highlighted the origin, much as we highlight the domain
> in the address bar?

To be clear, my suggestion in comment 3 is not necessarily endorsing a proposal that would cause the two types of names to be combined, with the only difference between the highlighting of a the origin. I don't think that would work as well in a compartment name as it does in the address bar.
> why would there be multiple compartments 

Sandboxes always get their own compartment, even if they share an origin with a page.  So you can have an arbitrarily large number of compartments all for the same url: they just need to be sandboxes initialized against that page.

I agree that we should format sandbox compartments and page compartments differently, though.  There's a separate bug on that.
(In reply to comment #5)
> 
> I agree that we should format sandbox compartments and page compartments
> differently, though.  There's a separate bug on that.

Is there?  It was discussed in dev-platform, but I don't know that a bug has been filed.
Hmm... I thought there was, but I don't see one, indeed.
I filed bug 673331 for that.
Keywords: privacy
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #9)
> Why is this a privacy concern?

Good question.  Perhaps it's potential leakage of data in the querystring?  Jesse, can you elaborate?

What gets access to the URL?  If it's just other chrome-priv stuff, I doubt it's a significant privacy issue.

-Sid
This is a privacy concern because we're asking people to paste the contents of about:memory into bug reports. The last time I did that, I had to hand-edit it.
No longer blocks: ZombieCompartments
I think compartment-per-global will fix this, because we'll no longer have compartments shared between multiple tabs.
Depends on: cpg
CPG ftw.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.