Third parties should be able to add panels via javascript, window.sidebar.addPanel("title","http://content_url","http://customize_url")

Re-summarized.

Sweep M13 bugs to M14.

So did Brendan ever check his stuff in?

This is part of the Beta 1 requirements so I'm nominating this as a "beta 1" blocker. Steve, did Brendan hose us and go off on sabbatical without checking his stuff into the tree?

We are hosed. Time for plan 'B': ugly hack.

my vote is that this needs to be in for beta 1

Clayton, can you help here? PDT+

Clayton - this is what we talked about this morning. This is a beta1 stopper approved by the PDT team and we hope that your team can take care of it working with slamm.

Clayton says that rginda will do the back end work that Brendan was supposed to do. Reassigning to rginda, then will later re-assign back to slamm when back end is ready.

No so much that Brendan was supposed to do. He was intending to finish this up even while on sabbatical. He deserves the time off. Rob offered to fill in. = C =

I havn't seen how brendan planned on solving this, but I'd like to propose that we broadcast when a new js environment has been created before nsJSContext::InitContext exits. The browser chrome could observe this, and modify the DOM of the content window as it sees fit. It would open up even more neat additions that automatically appear in each page, like IE DOM emulation, for example, and, in theory is a simple change. I've tested it with the current Browser:LoadingProgress broadcaster, and have been able to create new DOM elements with access to XPConnect. The only catch with the current observers is that the DOM changes dont appear until *after* the onLoad handler for the page has fired, so the page is restricted to accessing the new properties from events or timers.

These attachments should illustrate the basic idea. When loading the sample html page, the console displays: during load: sidebar is undefined after load: sidebar is undefined Document file:///home/rginda/src/moztests/random.html loaded successfully Document: Done (0.49 secs) sidebar_onLoadProgressChange: adding dom hook. after click: sidebar is [object Object] after click: calling addPanel: sidebar_addPanel: arguments were (arg 1, arg 2) sidebar_addPanel: sample XPCOM component is [xpconnect wrapped nsISample]

This idea has some unfortunate limitations, I'll be going with brendan's plan described in bug 21953. Hope to have code ready for review tomorrow, 2/10.

26725 is getting in the way, although there is a pref based workaround that will let me keep going for now.

dom changes sent to vidur for review, sidebar to slamm. These changes represent a hack to Get It Done for beta1. The real solution is to fix the nsIScriptNameSpaceManager interface to work with IID (and be scriptable.) Bug 21953 should be used to track the progress of the correct fix. Bug 26725 currently gets in the way of seeing this work in the tip. Adding pref("security.checkxpconnect", false); to all.js, and Applying appropriate comments to nsGlobalWindow.cpp:3239 (To prevent the following line from failing: if (NS_FAILED(secMan->GetSubjectPrincipal(getter_AddRefs(principal)))) return NS_ERROR_FAILURE; ) Should get you to the point where the attached test page can add content to your sidebar.

I just added a patch THAT SHOULD NOT BE CHECKED IN to show failure due to insufficent principals in jsloader. It gets the codebase principals for JS components (with url of http://www.mozilla.org/index.html). This patch will cause rginda's sidebar stuff to fail for me. While my previous patch with system principals causes it to work for me.

This patch doesn't seem to work on Linux. I'm going to apply the patches from the ground up on a fresh tree, just to be sure. 647 rv = secman->GetSystemPrincipal(getter_AddRefs(iPrincipals)); 648 if(NS_FAILED(rv) || !iPrincipals) 652 rv = iPrincipals->GetJSPrincipals(&jsPrincipals); 653 if(NS_FAILED(rv) || !jsPrincipals) (gdb) p jsPrincipals $1 = (JSPrincipals *) 0x8197b3c (gdb) p *jsPrincipals $2 = {codebase = 0x0, getPrincipalArray = 0x405f2d70, globalPrivilegesEnabled = 0x405f2d7c, refcount = 16, destroy = 0x405f2d90} 656 obj = JS_NewObject(mContext, &gGlobalClass, mSuperGlobal, NULL); <...> 685 if (NS_FAILED(rv)) 688 JSScript *script = JS_CompileFileHandleForPrincipals(mContext, obj, (const char *)displayPath, fileHandle, jsPrincipals); 695 if (!script) { 708 if (!JS_ExecuteScript(mContext, obj, script, &retval)) { JS Component Loader: ERROR (null):0 uncaught exception: Access denied to XPConnect service. 712 obj = nsnull;

Rob, I think you should drag norris into this. I can't see why this would not be working. Perhaps he will.

sidebar, dom, and jsloader changes checked in, the attached sidebar testcase should work (ie, it should add www.mozilla.org to your sidebar), sans isPanel, which was taken out due to security concerns.

Removing dependency on 21953. 21953 should be used to track a more 'correct' solution to the problem.

Verified on mac/linux/windows 2/16 using attached test case. However, your new panel is not seen in the current browser window (or any other open windows). To see the new panel, you must open a new window. Re-opening, because this is not how the customize dialogue works, so I'm guessing it can be done. Using the customize dialogue, all open windows are auto-magically updated once you save changes.

i'm going to mark this fixed, bug 28073 covers the remaining problem

marking verified