Last Comment Bug 664067 - Too many compartments for techcrunch.com
: Too many compartments for techcrunch.com
Status: RESOLVED FIXED
[MemShrink:P2]
: footprint
Product: Core
Classification: Components
Component: XPConnect (show other bugs)
: unspecified
: All All
: -- normal with 1 vote (vote)
: ---
Assigned To: Blake Kaplan (:mrbkap)
:
:
Mentors:
http://blog.mozilla.com/nnethercote/2...
Depends on: 634156
Blocks: mslim-fx5+
  Show dependency treegraph
 
Reported: 2011-06-13 20:14 PDT by Nicholas Nethercote [:njn]
Modified: 2012-01-14 00:28 PST (History)
18 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
compartments lists (29.88 KB, text/plain)
2011-06-13 20:14 PDT, Nicholas Nethercote [:njn]
no flags Details
Diff in the compartments list after landing bug 634156 (2.75 KB, text/plain)
2011-06-28 22:12 PDT, Nicholas Nethercote [:njn]
no flags Details
stack on creation of compartment for a Facebook "like" button (10.57 KB, text/plain)
2011-06-30 23:43 PDT, Nicholas Nethercote [:njn]
no flags Details

Description Nicholas Nethercote [:njn] 2011-06-13 20:14:09 PDT
Created attachment 539101 [details]
compartments lists

Loading the front page of techcrunch.com causes over 70 compartments to be created.  There are 20 stories on the front page.  Each story has a Facebook "like" button, a Facebook "send" button, and a Google "+1" button.  Each of those buttons has its own compartment.  In the "+1" cases, it's probably because they're https.  But for the 40 Facebook buttons (and three miscellaneous Facebook compartments) it's unclear why they have separate compartments, it looks like they could all be a single compartment.

Here's an example of two of the "like" button compartments;  this is the value of compartment->principals->codebase:

- http://www.facebook.com/plugins/like.php?api_key=113402378708388&channel_url=http%3A%2F%2Fstatic.ak.fbcdn.net%2Fconnect%2Fxd_proxy.php%3Fversion%3D3%23cb%3Df121e375152e72%26origin%3Dhttp%253A%252F%252Ftechcrunch.com%252Ff362aa336a1df18%26relation%3Dparent.parent%26transport%3Dpostmessage&href=http%3A%2F%2Ftechcrunch.com%2F2011%2F06%2F13%2Frescuetime-launches-introductions-a-carfax-report-for-top-job-candidates%2F&layout=button_count&locale=en_US&node_type=link&sdk=joey&show_faces=false&width=90

- http://www.facebook.com/plugins/like.php?api_key=113402378708388&channel_url=http%3A%2%2Fstatic.ak.fbcdn.net%2Fconnect%2Fxd_proxy.php%3Fversion%3D3%23cb%3Df130f5282966b26%26origin%3Dhttp%253A%252F%252Ftechcrunch.com%252Ff362aa336a1df18%26relation%3Dparent.parent%26transport%3Dpostmessage&href=http%3A%2%2Ftechcrunch.com%2F2011%2F06%2F13%2Ftech-giant-eats-your-lunch%2F&layout=button_count&locale=en_US&node_type=link&sdk=joey&show_faces=false&width=90

They differ only in the search parameters.

I've attached the full list of compartments.  Note that I special-case the printing of the atomsCompartment as "atoms".  (I got this list from a WIP patch for bug 661474.)
Comment 1 Nicholas Nethercote [:njn] 2011-06-13 20:26:22 PDT
FWIW, here's the memory report for a Facebook "like" button:

│  ├──────254,532 B (00.09%) -- compartment(http://www.facebook.com/plugins/likebox.php?id=8062627951&width=300&connections=10&stream=false&header=false&height=255)
│  │      ├──186,000 B (00.07%) -- tjit-data
│  │      │  ├──148,000 B (00.05%) -- allocators-reserve
│  │      │  └───38,000 B (00.01%) -- allocators-main
│  │      ├───65,536 B (00.02%) -- mjit-code
│  │      ├────2,592 B (00.00%) -- object-slots
│  │      ├──────404 B (00.00%) -- scripts
│  │      ├────────0 B (00.00%) -- string-chars
│  │      ├────────0 B (00.00%) -- mjit-data
│  │      └────────0 B (00.00%) -- tjit-code

The tjit-data and mjit-code space is almost entirely wasted, then multiple it by 40!  That's what prompted bug 661068.
Comment 2 Boris Zbarsky [:bz] (still a bit busy) 2011-06-14 13:05:57 PDT
What are the stacks to those compartment creations?  Last time you brought this up, this was due to us attaching a console to every iframe, and each console attachment needing a compartment for the sandbox it evaluates its stuff in....  Which raised the question of how long those compartments hang around, of course.
Comment 3 Nicholas Nethercote [:njn] 2011-06-14 23:06:34 PDT
(In reply to comment #2)
> What are the stacks to those compartment creations?  Last time you brought
> this up, this was due to us attaching a console to every iframe, and each
> console attachment needing a compartment for the sandbox it evaluates its
> stuff in....  Which raised the question of how long those compartments hang
> around, of course.

Below is the stack for one of the Facebook "like" buttons.  It does look sandbox-related.  The compartments hang around as long as the front page is open.  Does each "like" button get its own iframe?

#0  CreateNewCompartment (cx=0x7fffcc6ac800, clasp=0x7ffff7b54d80, 
    principal=<value optimised out>, priv=0x7fffcb298520, 
    global=0x7fffffff9bd0, compartment=0x7fffffff9bd8)
    at /home/njn/moz/mc1/js/src/xpconnect/src/nsXPConnect.cpp:1051
#1  0x00007ffff61da89e in xpc_CreateGlobalObject (cx=0x7fffcc6ac800, 
    clasp=0x7ffff7b54d80, principal=0x7fffcb9ec350, 
    ptr=<value optimised out>, wantXrays=true, global=0x7fffffff9bd0, 
    compartment=0x7fffffff9bd8)
    at /home/njn/moz/mc1/js/src/xpconnect/src/nsXPConnect.cpp:1084
#2  0x00007ffff61e8699 in xpc_CreateSandboxObject (cx=0x7fffcc6ac800, 
    vp=0x7fffe1eff1c8, prinOrSop=<value optimised out>, proto=0x0, 
    wantXrays=true)
    at /home/njn/moz/mc1/js/src/xpconnect/src/xpccomponents.cpp:3181
#3  0x00007ffff61e9be2 in nsXPCComponents_utils_Sandbox::CallOrConstruct (
    wrapper=<value optimised out>, cx=0x7fffcc6ac800, 
    obj=<value optimised out>, argc=<value optimised out>, 
    argv=<value optimised out>, vp=0x7fffe1eff1c8, _retval=0x7fffffff9f4c)
    at /home/njn/moz/mc1/js/src/xpconnect/src/xpccomponents.cpp:3373
#4  0x00007ffff61e9d5a in nsXPCComponents_utils_Sandbox::Call (
    this=<value optimised out>, wrapper=<value optimised out>, 
    cx=<value optimised out>, obj=<value optimised out>, 
    argc=<value optimised out>, argv=<value optimised out>, 
    vp=0x7fffe1eff1c8, _retval=0x7fffffff9f4c)
    at /home/njn/moz/mc1/js/src/xpconnect/src/xpccomponents.cpp:3248
#5  0x00007ffff6229f5c in XPC_WN_Helper_Call (cx=0x7fffcc6ac800, argc=1, 
    vp=0x7fffe1eff1c8)
    at /home/njn/moz/mc1/js/src/xpconnect/src/xpcwrappednativejsops.cpp:1054
#6  0x00007ffff6cc2898 in js::CallJSNative (cx=0x7fffcc6ac800, 
    native=0x7ffff6229cdc <XPC_WN_Helper_Call(JSContext*, uintN, jsval*)>, 
    argc=1, vp=0x7fffe1eff1c8)
    at /home/njn/moz/mc1/js/src/jscntxtinlines.h:277
#7  0x00007ffff6cbe6d6 in js::Invoke (cx=0x7fffcc6ac800, 
    argsRef=<value optimised out>, option=js::INVOKE_NORMAL)
    at /home/njn/moz/mc1/js/src/jsinterp.cpp:649
#8  0x00007ffff6f4a508 in js::Interpret (cx=<value optimised out>, 
    entryFrame=0x7fffe1eff148, interpMode=js::JSINTERP_NORMAL)
    at /home/njn/moz/mc1/js/src/jsinterp.cpp:4687
#9  0x00007ffff6cb890c in js::RunScript (cx=0x7fffcc6ac800, 
    script=0x7fffcd27fc00, fp=0x7fffe1eff148)
    at /home/njn/moz/mc1/js/src/jsinterp.cpp:613
#10 0x00007ffff6cbef5e in js::Invoke (cx=0x7fffcc6ac800, 
    argsRef=<value optimised out>, option=js::INVOKE_NORMAL)
    at /home/njn/moz/mc1/js/src/jsinterp.cpp:694
#11 0x00007ffff6cc0596 in js::ExternalInvoke (cx=0x7fffcc6ac800, thisv=..., 
    fval=..., argc=1, argv=0x7fffffffb1e0, rval=0x7fffffffaff0)
    at /home/njn/moz/mc1/js/src/jsinterp.cpp:816
#12 0x00007ffff6c0f9d5 in JS_CallFunctionValue (cx=0x7fffcc6ac800, 
    obj=<value optimised out>, fval=..., argc=1, argv=0x7fffffffb1e0, 
    rval=0x7fffffffaff0) at /home/njn/moz/mc1/js/src/jsapi.cpp:5087
#13 0x00007ffff62143c5 in nsXPCWrappedJSClass::CallMethod (
    this=<value optimised out>, wrapper=<value optimised out>, methodIndex=3, 
    info=0x7fffe4e6afc0, nativeParams=0x7fffffffb310)
    at /home/njn/moz/mc1/js/src/xpconnect/src/xpcwrappedjsclass.cpp:1662
#14 0x00007ffff620c08c in nsXPCWrappedJS::CallMethod (this=0x7fffc6426d80, 
    methodIndex=3, info=0x7fffe4e6afc0, params=0x7fffffffb310)
    at /home/njn/moz/mc1/js/src/xpconnect/src/xpcwrappedjs.cpp:586
#15 0x00007ffff698776c in PrepareAndDispatch (self=0x7fffca0e1b00, 
    methodIndex=<value optimised out>, args=<value optimised out>, 
    gpregs=0x7fffffffb3f0, fpregs=0x7fffffffb420)
    at /home/njn/moz/mc1/xpcom/reflect/xptcall/src/md/unix/xptcstubs_x86_64_linux.cpp:153
#16 0x00007ffff6986aff in SharedStub () from d64/dist/bin/libxul.so
#17 0x00007ffff5d86dc5 in nsWindowSH::GlobalResolve (aWin=0x7fffca412800, 
    cx=0x7fffcc6ac800, obj=0x7fffce8e1ce8, id=..., did_resolve=0x7fffffffb700)
    at /home/njn/moz/mc1/dom/base/nsDOMClassInfo.cpp:6656
#18 0x00007ffff5d87ae7 in nsWindowSH::NewResolve (this=0x7fffda575670, 
    wrapper=0x7fffd38b30b0, cx=0x7fffcc6ac800, obj=0x7fffce8e1ce8, 
    id=<value optimised out>, flags=4, objp=0x7fffffffb9c0, 
    _retval=0x7fffffffb9cc)
    at /home/njn/moz/mc1/dom/base/nsDOMClassInfo.cpp:6899
#19 0x00007ffff622cb47 in XPC_WN_Helper_NewResolve (cx=0x7fffcc6ac800, 
    obj=0x7fffce8e1ce8, id=<value optimised out>, flags=4, 
    objp=0x7fffffffba78)
    at /home/njn/moz/mc1/js/src/xpconnect/src/xpcwrappednativejsops.cpp:1161
#20 0x00007ffff6cdddd6 in CallResolveOp (cx=0x7fffcc6ac800, 
    obj=0x7fffce8e1ce8, id=<value optimised out>, flags=65535, 
    objp=0x7fffffffbb38, propp=0x7fffffffbb30)
    at /home/njn/moz/mc1/js/src/jsobj.cpp:4858
#21 LookupPropertyWithFlagsInline (cx=0x7fffcc6ac800, obj=0x7fffce8e1ce8, 
    id=<value optimised out>, flags=65535, objp=0x7fffffffbb38, 
    propp=0x7fffffffbb30) at /home/njn/moz/mc1/js/src/jsobj.cpp:4917
#22 0x00007ffff6cde379 in js::LookupPropertyWithFlags (cx=0x7fffcc6ac800, 
    obj=0x7fffce8e1ce8, id=<value optimised out>, flags=65535, 
    objp=0x7fffffffbb38, propp=0x7fffffffbb30)
    at /home/njn/moz/mc1/js/src/jsobj.cpp:4982
#23 0x00007ffff6cde490 in js_FindPropertyHelper (cx=0x7fffcc6ac800, 
    id=<value optimised out>, cacheResult=1, objp=0x7fffffffc0d8, 
    pobjp=0x7fffffffc018, propp=0x7fffffffbee8)
    at /home/njn/moz/mc1/js/src/jsobj.cpp:5008
#24 0x00007ffff6f4b0c4 in js::Interpret (cx=<value optimised out>, 
    entryFrame=0x7fffe1eff048, interpMode=js::JSINTERP_NORMAL)
    at /home/njn/moz/mc1/js/src/jsinterp.cpp:4754
#25 0x00007ffff6cb890c in js::RunScript (cx=0x7fffcc6ac800, 
    script=0x7fffc6011000, fp=0x7fffe1eff048)
    at /home/njn/moz/mc1/js/src/jsinterp.cpp:613
#26 0x00007ffff6cba0ce in js::Execute (cx=0x7fffcc6ac800, chain=..., 
    script=0x7fffc6011000, prev=<value optimised out>, flags=0, result=0x0)
    at /home/njn/moz/mc1/js/src/jsinterp.cpp:974
#27 0x00007ffff6c0bd8f in EvaluateUCScriptForPrincipalsCommon (
    cx=0x7fffcc6ac800, obj=0x7fffce8e1ce8, principals=0x7fffcb9ec358, 
    chars=0x7fffc9c79008, length=25739, filename=<value optimised out>, 
    lineno=1, rval=0x0, compileVersion=JSVERSION_DEFAULT)
    at /home/njn/moz/mc1/js/src/jsapi.cpp:4973
#28 0x00007ffff6c0c3fe in JS_EvaluateUCScriptForPrincipalsVersion (
    cx=0x7fffcc6ac800, obj=0x7fffce8e1ce8, principals=0x7fffcb9ec358, 
    chars=0x7fffc9c79008, length=25739, 
    filename=0x7fffca4a87e8 "http://static.ak.fbcdn.net/rsrc.php/v1/yY/r/eptfJSfAjrr.js", lineno=1, rval=0x0, version=JSVERSION_DEFAULT)
    at /home/njn/moz/mc1/js/src/jsapi.cpp:4989
#29 0x00007ffff5d0eb50 in nsJSContext::EvaluateString (this=0x7fffce026e80, 
    aScript=..., aScopeObject=0x7fffce8e1ce8, 
    aPrincipal=<value optimised out>, 
    aURL=0x7fffca4a87e8 "http://static.ak.fbcdn.net/rsrc.php/v1/yY/r/eptfJSfAjrr.js", aLineNo=1, aVersion=0, aRetValue=0x0, aIsUndefined=0x7fffffffc87c)
    at /home/njn/moz/mc1/dom/base/nsJSEnvironment.cpp:1453
#30 0x00007ffff5a6e87a in nsScriptLoader::EvaluateScript (
    this=0x7fffcc59a600, aRequest=<value optimised out>, aScript=...)
    at /home/njn/moz/mc1/content/base/src/nsScriptLoader.cpp:906
#31 0x00007ffff5a6f028 in nsScriptLoader::ProcessRequest (
    this=0x7fffcc59a600, aRequest=0x7fffca49d220)
    at /home/njn/moz/mc1/content/base/src/nsScriptLoader.cpp:799
#32 0x00007ffff5a712d9 in nsScriptLoader::ProcessScriptElement (
    this=0x7fffcc59a600, aElement=0x7fffc6413398)
    at /home/njn/moz/mc1/content/base/src/nsScriptLoader.cpp:646
#33 0x00007ffff5a6aedf in nsScriptElement::MaybeProcessScript (
    this=0x7fffc6413398)
    at /home/njn/moz/mc1/content/base/src/nsScriptElement.cpp:182
#34 0x00007ffff5bb81ad in nsHTMLScriptElement::MaybeProcessScript (
    this=0x7fffc6413320)
    at /home/njn/moz/mc1/content/html/content/src/nsHTMLScriptElement.cpp:586
#35 0x00007ffff5bb6c19 in nsHTMLScriptElement::DoneAddingChildren (
    this=0x7fffc6413320, aHaveNotified=<value optimised out>)
    at /home/njn/moz/mc1/content/html/content/src/nsHTMLScriptElement.cpp:513
#36 0x00007ffff5ed629a in nsHtml5TreeOpExecutor::RunScript (
    this=0x7fffcde56380, aScriptElement=0x7fffc6413320)
    at /home/njn/moz/mc1/parser/html/nsHtml5TreeOpExecutor.cpp:730
#37 0x00007ffff5ed6fda in nsHtml5TreeOpExecutor::RunFlushLoop (
    this=0x7fffcde56380)
    at /home/njn/moz/mc1/parser/html/nsHtml5TreeOpExecutor.cpp:525
#38 0x00007ffff5ed76e9 in nsHtml5ExecutorReflusher::Run (this=0x7fffca4685e0)
    at /home/njn/moz/mc1/parser/html/nsHtml5TreeOpExecutor.cpp:90
#39 0x00007ffff696c4e5 in nsThread::ProcessNextEvent (this=0x7fffec72aaa0, 
    mayWait=0, result=0x7fffffffd2ec)
    at /home/njn/moz/mc1/xpcom/threads/nsThread.cpp:618
#40 0x00007ffff69030e8 in NS_ProcessNextEvent_P (
    thread=<value optimised out>, mayWait=0)
    at /home/njn/moz/mc1/d64/xpcom/build/nsThreadUtils.cpp:245
#41 0x00007ffff67dd3cb in mozilla::ipc::MessagePump::Run (
    this=0x7fffea053440, aDelegate=0x7fffec7b18f0)
    at /home/njn/moz/mc1/ipc/glue/MessagePump.cpp:110
#42 0x00007ffff69b202c in MessageLoop::RunInternal (this=0x7fffec7b18f0)
    at /home/njn/moz/mc1/ipc/chromium/src/base/message_loop.cc:218
#43 0x00007ffff69b203b in MessageLoop::RunHandler (this=<value optimised out>)
    at /home/njn/moz/mc1/ipc/chromium/src/base/message_loop.cc:202
#44 0x00007ffff69b2391 in MessageLoop::Run (this=0x7fffec7b18f0)
    at /home/njn/moz/mc1/ipc/chromium/src/base/message_loop.cc:176
#45 0x00007ffff6684b34 in nsBaseAppShell::Run (this=0x7fffea02a740)
    at /home/njn/moz/mc1/widget/src/xpwidgets/nsBaseAppShell.cpp:189
#46 0x00007ffff63dff13 in nsAppStartup::Run (this=0x7fffe4148830)
    at /home/njn/moz/mc1/toolkit/components/startup/nsAppStartup.cpp:222
---Type <return> to continue, or q <return> to quit---
#47 0x00007ffff54176c4 in XRE_main (argc=<value optimised out>, 
    argv=<value optimised out>, aAppData=<value optimised out>)
    at /home/njn/moz/mc1/toolkit/xre/nsAppRunner.cpp:3699
#48 0x0000000000401d87 in main (argc=4, argv=0x7fffffffdd18)
    at /home/njn/moz/mc1/browser/app/nsBrowserApp.cpp:158
Comment 4 Boris Zbarsky [:bz] (still a bit busy) 2011-06-15 09:12:44 PDT
> Does each "like" button get its own iframe?

Yep.  Also each Facebook "Send" button, each Google +1 button, each "Tweet" button.  So 4 frames per post.  Of course we only need to create the sandbox if the script in that frame calls console APIs.... but I bet they do.

The fact that these sandbox compartments stick around is sadmaking, though.  Can we make that stop happening?
Comment 5 Nicholas Nethercote [:njn] 2011-06-28 22:12:11 PDT
Created attachment 542723 [details]
Diff in the compartments list after landing bug 634156

With 634156 landed, I now get 33 compartments for TechCrunch, down from 75.  If I sort them and remove all the search parts of the URLs, I get the attached result.  The following compartments have gone:

https://clients6.google.com/static/proxy.html
https://plusone.google.com/u/0/_/+1/button x 20
http://view.atdmt.com/M0N/iview/314366792/direct;wi.728;hi.90/01/18425725
http://www.facebook.com/plugins/likebox.php
http://www.facebook.com/plugins/send.php x 20

That seems good, but is it expected?  It's odd that we now have no google.com compartments.  (Oh, it looks like those +1 buttons are no longer on techcrunch.com!)  Also weird that the Facebook "send" button compartments have disappeared but the "like" button compartments have not.
Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2011-06-28 22:43:16 PDT
The facebook send and like buttons are likely same-origin and hence share compartments, no?  Before there were unique compartments because sandboxes always get those...

Which makes me wonder why we have multiple like.php compartments.  Are there still sandboxes somewhere here?
Comment 7 Nicholas Nethercote [:njn] 2011-06-28 23:17:34 PDT
(In reply to comment #6)
> The facebook send and like buttons are likely same-origin and hence share
> compartments, no? 

Could be.  Does compartment->principals->codebase get assigned the URL of the first script that runs in the compartment?  Is it the best thing to be printing in the per-compartment reporters (bug 661474)?
Comment 8 Boris Zbarsky [:bz] (still a bit busy) 2011-06-28 23:27:47 PDT
> Does compartment->principals->codebase get assigned the URL of the first script
> that runs in the compartment?

The url of the first page that loaded a script that runs in the compartment, yes.

> Is it the best thing to be printing in the per-compartment reporters (bug
> 661474)?

Probably, yeah...  The other option is to just print the origin, but that's strictly less data.  On the other hand, that's what's used to decide whether to share compartments.
Comment 9 Nicholas Nethercote [:njn] 2011-06-28 23:30:22 PDT
(In reply to comment #8)
> The other option is to just print the origin, but that's
> strictly less data.  On the other hand, that's what's used to decide whether
> to share compartments.

If we only printed the origin it would have been much less clear that the "like" and "send" buttons were the culprits here, so I'll keep printing the full URL.  Thanks.
Comment 10 Nicholas Nethercote [:njn] 2011-06-30 22:59:11 PDT
Huh, I just looked again, there are now only 8 compartments, 3 of which are always present in Firefox!

 http://techcrunch.com/
 [System Principal]
 atoms
 http://www.facebook.com/extern/login_status.php
 http://cdn.at.atwola.com/_media/uac/tcode3.html
 http://googleads.g.doubleclick.net/pagead/ads
 http://www.facebook.com/plugins/recommendations.php
 moz-nullprincipal:{af11fdbc-bc31-4892-8c27-48a381c4f16b}

That's despite the Google +1 buttons having returned.

Is this our change?  Or I wonder if someone at TechCrunch read http://blog.mozilla.com/nnethercote/2011/06/21/you-make-what-you-measure/ -- it did get a mention on Reddit -- and changed their code?
Comment 11 Nicholas Nethercote [:njn] 2011-06-30 23:11:12 PDT
Oh wait, it appears now that the button crap for each story now doesn't get loaded until you mouse over the story.  After mousing over all stories, I'm back to 70 compartments:

atoms
http://cdn.at.atwola.com/_media/uac/tcode3.html
http://googleads.g.doubleclick.net/pagead/ads
http://platform.twitter.com/widgets/tweet_button.html
https://clients6.google.com/static/proxy.html
https://clients6.google.com/static/proxy.html
https://clients6.google.com/static/proxy.html
https://clients6.google.com/static/proxy.html
https://clients6.google.com/static/proxy.html
https://clients6.google.com/static/proxy.html
https://clients6.google.com/static/proxy.html
https://clients6.google.com/static/proxy.html
https://clients6.google.com/static/proxy.html
https://clients6.google.com/static/proxy.html
https://clients6.google.com/static/proxy.html
https://clients6.google.com/static/proxy.html
https://clients6.google.com/static/proxy.html
https://clients6.google.com/static/proxy.html
https://clients6.google.com/static/proxy.html
https://clients6.google.com/static/proxy.html
https://clients6.google.com/static/proxy.html
https://clients6.google.com/static/proxy.html
https://clients6.google.com/static/proxy.html
https://clients6.google.com/static/proxy.html
https://plusone.google.com/u/0/_/+1/button
https://plusone.google.com/u/0/_/+1/button
https://plusone.google.com/u/0/_/+1/button
https://plusone.google.com/u/0/_/+1/button
https://plusone.google.com/u/0/_/+1/button
https://plusone.google.com/u/0/_/+1/button
https://plusone.google.com/u/0/_/+1/button
https://plusone.google.com/u/0/_/+1/button
https://plusone.google.com/u/0/_/+1/button
https://plusone.google.com/u/0/_/+1/button
https://plusone.google.com/u/0/_/+1/button
https://plusone.google.com/u/0/_/+1/button
https://plusone.google.com/u/0/_/+1/button
https://plusone.google.com/u/0/_/+1/button
https://plusone.google.com/u/0/_/+1/button
https://plusone.google.com/u/0/_/+1/button
https://plusone.google.com/u/0/_/+1/button
https://plusone.google.com/u/0/_/+1/button
https://plusone.google.com/u/0/_/+1/button
https://plusone.google.com/u/0/_/+1/button
http://static.ak.fbcdn.net/connect/xd_proxy.php
http://techcrunch.com/
http://www.facebook.com/extern/login_status.php
http://www.facebook.com/plugins/like.php
http://www.facebook.com/plugins/like.php
http://www.facebook.com/plugins/like.php
http://www.facebook.com/plugins/like.php
http://www.facebook.com/plugins/like.php
http://www.facebook.com/plugins/like.php
http://www.facebook.com/plugins/like.php
http://www.facebook.com/plugins/like.php
http://www.facebook.com/plugins/like.php
http://www.facebook.com/plugins/like.php
http://www.facebook.com/plugins/like.php
http://www.facebook.com/plugins/like.php
http://www.facebook.com/plugins/like.php
http://www.facebook.com/plugins/like.php
http://www.facebook.com/plugins/like.php
http://www.facebook.com/plugins/like.php
http://www.facebook.com/plugins/like.php
http://www.facebook.com/plugins/like.php
http://www.facebook.com/plugins/like.php
http://www.facebook.com/plugins/like.php
http://www.facebook.com/plugins/recommendations.php
moz-nullprincipal:{af11fdbc-bc31-4892-8c27-48a381c4f16b}
[System Principal]
Comment 12 Boris Zbarsky [:bz] (still a bit busy) 2011-06-30 23:22:06 PDT
What do the stacks for those compartment creations look like?
Comment 13 Nicholas Nethercote [:njn] 2011-06-30 23:43:14 PDT
Created attachment 543362 [details]
stack on creation of compartment for a Facebook "like" button

> What do the stacks for those compartment creations look like?

I've attached the stack for the creation of "http://www.facebook.com/plugins/like.php?api_key=187288694643718&channel_url=http%3A%2F%2Fstatic.ak.fbcdn.net%2Fconnect%2Fxd_proxy.php%3Fversion%3D3%23cb%3Df350c8bf4383caa%26origin%3Dhttp%253A%252F%25" (I think that was truncated in gdb), which happened when I moused over the first story.  Looks like sandboxes are still involved.
Comment 14 Boris Zbarsky [:bz] (still a bit busy) 2011-06-30 23:46:40 PDT
Yep.  What does the JS stack look like there?
Comment 15 Nicholas Nethercote [:njn] 2011-06-30 23:53:21 PDT
(In reply to comment #14)
> Yep.  What does the JS stack look like there?

How do I get the JS stack?
Comment 16 Johnny Stenback (:jst, jst@mozilla.com) 2011-07-01 00:11:08 PDT
XPConnect includes a DumpJSStack() function that you can call from gdb, that should give you the JS stack.
Comment 17 Nicholas Nethercote [:njn] 2011-07-01 00:15:45 PDT
(gdb) call DumpJSStack()
0 CA_init(aWindow = [object Window @ 0x7fffcf3b0eb0 (native @ 0x7fffced9ec78)]) ["file:///home/njn/moz/mi4/d64/dist/bin/components/ConsoleAPI.js":98]
    contentObject = undefined
    sandbox = undefined
    chromeObject = [object Object]
    self = [object Object]
    id = 64
    this = [object Object]
1 <TOP LEVEL> ["<unknown>":0]
    <failed to get 'this' value>
2 <TOP LEVEL> ["http://static.ak.fbcdn.net/rsrc.php/v1/yT/r/hynWVIhu14h.js":7]
    this = [object Window @ 0x7fffcf3b0eb0 (native @ 0x7fffced9ec78)]
[New Thread 0x7fffd73ff700 (LWP 8061)]
Comment 18 Boris Zbarsky [:bz] (still a bit busy) 2011-07-01 00:19:32 PDT
Yeah, that's what was producing the sandboxes earlier... I thought bug 634156 was supposed to fix that issue.  And in fact, line 98 of ConsoleAPI.js is a sandbox constructor call before that patch, but something totally different after.  Do you have that patch in the tree you're testing in?  Note that it's not on m-c yet.
Comment 19 Nicholas Nethercote [:njn] 2011-07-01 02:56:22 PDT
Ah, it's only fixed-in-tracemonkey.  So I don't have that patch applied.  I'll try again early next week once the merge has happened.  Thanks for working it out.
Comment 20 Nicholas Nethercote [:njn] 2011-07-05 19:31:24 PDT
(In reply to comment #19)
> Ah, it's only fixed-in-tracemonkey.  So I don't have that patch applied. 
> I'll try again early next week once the merge has happened.

Here's the list:

 atoms
 http://cdn.at.atwola.com/_media/uac/tcode3.html
 http://googleads.g.doubleclick.net/pagead/ads
 http://platform.twitter.com/widgets/tweet_button.html
 https://clients6.google.com/static/proxy.html
 https://plusone.google.com/u/0/_/+1/button
 http://static.ak.fbcdn.net/connect/xd_proxy.php
 http://techcrunch.com/
 http://www.facebook.com/extern/login_status.php
 moz-nullprincipal:{a8c86f08-77db-4d9e-a48d-e2b4b75fd3db}
 [System Principal]

Only 8 non-Firefox compartments!  And I also tested with a recent browesr build that lacked this patch, just to make sure that TechCrunch.com hasn't changed their site, and I got the usual 70-ish compartments.

Time to declare victory!  Great work with bug 634156, mrbkap.
Comment 21 Nicholas Nethercote [:njn] 2011-07-08 20:25:09 PDT
Good thing we fixed this:

http://techcrunch.com/2011/07/08/heads-up-techcrunch-will-look-a-little-different-next-week/

There goes our stress test :/

Note You need to log in before you can comment on or make changes to this bug.