Closed Bug 20721 Opened 20 years ago Closed 20 years ago

Javascript API to add Sidebar panels

Categories

(SeaMonkey :: Sidebar, defect, P1)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: slamm, Assigned: rginda)

References

Details

(Whiteboard: [PDT+])

Attachments

(7 files)

Third parties should be able to add panels via javascript,

window.sidebar.addPanel("title","http://content_url","http://customize_url")
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: M13
Blocks: 21564
Depends on: 21953
Blocks: 22176
Summary: [FEATURE] JS API to add panels → [FEATURE] Javascript API to add Sidebar panels
Re-summarized.
Blocks: 24206
Target Milestone: M13 → M14
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?
Keywords: beta1
We are hosed. Time for plan 'B': ugly hack. 
Summary: [FEATURE] Javascript API to add Sidebar panels → [BETA] Javascript API to add Sidebar panels
Priority: P2 → P1
Blocks: 26073
my vote is that this needs to be in for beta 1
Clayton, can you help here? PDT+
Whiteboard: [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.
Assignee: slamm → rginda
Status: ASSIGNED → NEW
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]

Summary: [BETA] Javascript API to add Sidebar panels → Javascript API to add Sidebar panels
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.
Depends on: 26725
Attached patch sidebar diffsSplinter Review
Attached patch dom diffsSplinter Review
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;
Status: NEW → ASSIGNED
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.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Removing dependency on 21953.  21953 should be used to track a more 'correct'
solution to the problem.
No longer depends on: 21953
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
i'm going to mark this fixed, bug 28073 covers the remaining problem
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
marking verified
Status: RESOLVED → VERIFIED
No longer blocks: 21564
No longer blocks: 22176
No longer blocks: 24206
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.