Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Identify TabChildGlobals in about:memory/compartment

RESOLVED FIXED in mozilla22

Status

()

Core
DOM
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: smaug, Assigned: smaug)

Tracking

unspecified
mozilla22
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [MemShrink:P2])

Attachments

(1 attachment)

5.35 KB, patch
Justin Lebar (not reading bugmail)
: review+
Details | Diff | Splinter Review
(Assignee)

Description

5 years ago
Created attachment 715642 [details] [diff] [review]
patch

https://tbpl.mozilla.org/?tree=Try&rev=7b92c1f20459
Attachment #715642 - Flags: review?(justin.lebar+bug)
Whiteboard: [MemShrink]
It looks like this names the compartments as

  compartment(inProcessTabChildGlobal?ownedby=http://foobar)

?

We do system principal compartments as

  compartment([System Principal], http://foobar)

so perhaps we should stay in line with that and do something like

  compartment([In-process TabChild], http://foobar)

?  I bet njn has an opinion too.  :)
(Assignee)

Comment 2

5 years ago
TabChildGlobal use system principal, so they should have [System Principal]
(Assignee)

Comment 3

5 years ago
and http://... doesn't make sense. TabChildGlobals aren't really in any URL.
Some page may own the element which then owns the TabChildGlobal (in case of in-process).


But I can change the ID to whatever feels the best :)
I rarely use about:memory/compartment so I'm not really familiar with conventions there.
So the current patch gives us

  compartment([System Principal], inProcessTabChildGlobal?ownedby=...)

?
(Assignee)

Comment 5

5 years ago
Yes
[System Principal], inProcessTabChildGlobal?ownedBy=chrome://browser/content/browser.xul [3]
More specific naming of compartments is always good...

What name would these compartments have had before?

How likely is the case where there isn't an "ownedBy" part?
(Assignee)

Comment 7

5 years ago
Before the patch out-of-process tabchildglobals are just
[System Principal]

and in-process tabchildglobals are
[System Principal|, chrome://browser/content/browser.xul
which less-nicely mixes them with other system compartments.
I mean, the top level chrome doc has chrome://browser/content/browser.xul as document uri, and the
same is used for tabchildglobals, so they all are reported to be similar things.
Whiteboard: [MemShrink] → [MemShrink:P2]
> [System Principal], inProcessTabChildGlobal?ownedBy=chrome://browser/content/browser.xul [3]

It's a bit ugly but I can't think of anything obviously better.  Go for it.
Attachment #715642 - Flags: review?(justin.lebar+bug) → review+
(Assignee)

Comment 9

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/7c4498f0fd07
https://hg.mozilla.org/mozilla-central/rev/7c4498f0fd07
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla22
This change just led to bug 842710 being filed -- another case of "if we measure it, we find problems with it".  Nice work.
(Assignee)

Comment 12

5 years ago
You mean bug 844661
You need to log in before you can comment on or make changes to this bug.