InformAction Forums

/edit: Please see my last post: http://forums.informaction.com/viewtopi ... 696#p38697

How many NoScript::ScriptSurrogate compartments should there be at a time at most?

Depends on how many surrogates you have defined and how many of them are triggered given the sites/tabs open at any given time. Why?

Well, I guess surrogate scripts don't run in-parallel, so why should the number of surrogates on a site matter?

I was wondering on how to interpret the outputs of about:compartments, say after a normal browsing session I open about:memory and then about:compartments I see: Now I would understand there is one compartment for the last site visited site, but why are there sometimes more? (oh and let's not forget, why even on about: pages at all?)

dhouwn wrote:Well, I guess surrogate scripts don't run in-parallel, so why should the number of surrogates on a site matter?

I was just investigating a user's reported site that happened to call to two sources of surrogates, google-analytics and quantserve. (not related to user's issue)

about:memory?verbose showed two NoScript compartments, which corresponds to the two surrogates running. Makes perfect sense to me. (shrug)
(plus one for about:support)

I think GµårÐïåñ was asking why this information was relevant, or what sort of problem you're finding here.

dhouwn, may I suggest you read and follow the Memory Project here (http://blog.mozilla.org/nnethercote/feed/) so you get the understanding of what's been going on with Fx memory, how its been changed, restructured, what steps are being taken to make it better, more understandable and the limitations of its show interface, be it about:memory or whatever, and how to interpret the data. Which addons are the worst offenders of making bad use of the memory, causing leaks and just outright screwing things up. Also how good addons, NS included, that are built right properly discard their usage as they free up.

Now all that being said, the compartments have a certain TTL (time to live, not unlike the network packet concept but obviously not in the same sense) and depend on the object that created them, when, for what, and how long it is needed, any remaining hooks to it, so on and so forth. So they are created as needed and sometimes that compartment will contain the reserved space for the sake of redundancy or sometimes because before the hold time expired (the time it will hold before discard) it was reset with another hit. Make sense?

Also not sure what version you are using, but there is no about:compartments as an option as of Fx 12, unless added in the nightlies. I use about:memory?verbose and get everything I need there.

It was added with Firefox 13. I follow the blog you mentioned. I not quite get why these compartments should be retained when what they do (running surrogate scripts) is stateless.
And finally why would more than 1 NoScript surrogate compartment just show for some about: pages?
When I open all about: pages from about:about, I see the following (one about:nosquint is from an add-on): No matter how many tabs of "normal" webpages I have open, I see just one compartment in such a case, so I believe there might be a bug. Reproduced under Aurora and Nightly with a test profile where all add-ons but NoScript were deactivated.

Steps to reproduce:

1. get Firefox Beta or newer
2. open about:about
3. middle- or shift-click on all entries there (open in new tab)
4. switch to or open another about:compartments tab
5. see at least 6 NoScript entries under the System Compartments tab
6. even if you do "Minimize memory usage" under about:memory they will stay as long as the tabs with them stay open, this is not the case with non-about: pages

I am sure Giorgio can elaborate on this, but it might be due to some changes in the browser that introduced this behavior or part of the initialization because NS operates at a very low level (aka kernel) level. So I am sure Giorgio would look into this but given that his extension was one of the 100+ that was tested for "leaks" and "problems" and passed with flying colors without issue, I am assuming the head of the memory project knows something that is being missed here or something would have been said about it.

There's no mystery here.
Those "Surrogate" compartments are created and bound to the page until it's alive on any whitelisted page (no matter if about: or http:), because NoScript uses the Surrogate mechanism also to provide some "patches" to the default page environment, e.g. toStaticHTML() or the hooks to allow WebGL blocking.
The compartment needs to be alive until the page exists because some of these hooks register event listeners, which must run in the same compartment as the one where they've been created.

Giorgio Maone wrote:Those "Surrogate" compartments are created and bound to the page until it's alive on any whitelisted page (no matter if about: or http:)

So I was just unlucky in not seeing it on several http pages?

Giorgio Maone wrote:The compartment needs to be alive until the page exists because some of these hooks register event listeners, which must run in the same compartment as the one where they've been created.

OK, that makes sense but on another note, why run them on about: pages at all? I can't think of many reasonable use cases, but I guess the overhead is negligible…

dhouwn, as I promised, I asked Giorgio to give some feedback and Giorgio, thank you for the input and also the validation of what I had said in my earlier post. Thank you and hopefully this resolves this matter.