According to my discussion with dveditz on irc.mozilla.org there is no easy way to register a sidebar panel that has been installed via XPI into local-panels.rdf so it will show up in the sidebar list. I am creating a sidebar panel that displays a list of all the links in the document displayed in the browser pane. This requires me to have the panel be part of the chrome in order to access the proper DOM nodes. Installing the panel via XPI is simple, but I do not know any way to add the panel to the sidebar without user intervention. Currently I must modify local-panels.rdf by hand. This panel will not work outside of the chrome, it must be part of the browser in order to function. Signing is another potential solution, but I lack the money to pursue that course of action. This is with Build 2000081704 PS: If I got the CC's wrong I apologize for any spam ------- Additional Comments From Ben Bucksch 2000-10-01 10:24 ------- Also important for panels the user wants to install locally for spped or privacy reasons. Nominating for mozilla1.0, important for diversity on panel options. Why can't you call the same function in the install script that you would call, if the user clicked on a "add panel x to your sidebar" link on a webpage? ------- Additional Comments From Eric Hodel 2000-10-02 01:06 ------- Registering a panel into local-panels.rdf allows the panel to show up in the list of available panels when you customize your sidebar. This is the same list you would choose something the mapquest, netscape network, and other panels from. Registering into local-panels.rdf does not add the panel to the sidebar. I'll double check to see the exact path to the local-panels.rdf file I am refering to and report back. ------- Additional Comments From Ben Bucksch 2000-10-02 03:15 ------- Right, my fault. ------- Additional Comments From dveditz@netscape.com 2000-10-02 09:56 ------- Taking bug and changing component. The Sidebar is not at fault here, it's a lack in the install engine. ------- Additional Comments From jimmylee@netscape.com 2000-10-02 10:03 ------- Ccing David. ------- Additional Comments From dveditz@netscape.com 2000-12-14 22:41 ------- *** Bug 62915 has been marked as a duplicate of this bug. *** ------- Additional Comments From ruth@innocent.com 2001-02-21 10:58 ------- We could do with this too, as could all Third Party sidebar hackers. It would be fairly easy to provide some stock JS which did this, if only Components was usable from XPI. No-one has provided me with a convincing explanation for it not being available - can we try enabling it in nightly builds and see what happens? NB This is not a security issue, XPI has privs to run native code and Components can do no worse than that. ------- Additional Comments From dveditz@netscape.com 2001-03-22 12:20 ------- renominating ------- Additional Comments From Jaime Rodriguez, Jr. 2001-04-12 09:24 ------- Dan - Where are we on the this one? do we have a chance to get it in for nsbeta1? Do you need anything from the PM and business side to make a case for this enhancement? Please Advise . . . Adding roberts and bobj to cc: list.

The following defines the problem(s) as I see it, and proposes a solution. Problems -------- The following are some of the problems resulting from our use of a static, monolithic panels.rdf file. - users can install a subset of NS 6, but panels.rdf will include options that were not installed. - uninstalling a component does not result in its removal from panels.rdf - the panels.rdf file from a previous install persists after upgrade. Any new panels in the default panels.rdf introduced by a new install will not make it into the users sidebar. Likewise, panels that reflect a feature from the previous install not present in the new install will be present in the panels.rdf file. An example of this is when the user installs mozilla over an NS 6 install; the sidebar will have an Instant Messenger panel which is not usable. Solution -------- The following segmentation of sidebar panels could be used to implement a solution to the above problems. 1. each product (mozilla, NS, beonex, etc.) will define a set of panels that reflect features that are a part of the core product, e.g., search, what's related, etc. These core panels are never removed from the product, and the features tied to them are not optional but required. These core panels should go away if the user upgrades the product or replaces it with another mozilla-based, in deference to the core panels supplied by the new version of the browser being installed. 2. each product defines a set of panels that refer to features that can be optionally installed, installed at a later time, or removed. These panels can only be added to or removed from the product via the installer, and map directly to the XPI file bound to the feature. Like the panels in 1, above, these panels should be removed if the user upgrades the product or replaces it with another mozilla-based browser. 3. each product allows the user to add (and remove?) panels that have been downloaded from the network from sites that provide sidebar content e.g., CNN. These panels should persist across upgrades or product replacement. Proposed Implementation ----------------------- A single "vendor-panels.rdf" file located below the bin (install) directory can be used to implement the panels described by 1, above. This file would be replaced by subsequent upgrades, or re-installs, of the product by the installer. To implement the panels described by 2, above, a directory also located in the install directory could be used to store panels.rdf files for each feature that can be optionally installed or removed from the product. Each component (IM for example) that has a sidebar panel would provide a uniquely named panels.rdf file in this directory as a part of the component's XPI file. Thus, the directory acts as a optional panels registry. The installer would make sure that this file is placed in the directory upon component install, and removed if the component it is bound to is ever uninstalled. Finally, custom panels would be stored in a "custom-panels.rdf" file that is located in the profile directory of each user, just as is the current panels.rdf file (the difference now is that we have factored out the product components). This file would never be removed by the installer, and would persist between upgrades and client installs. The sidebar datasource can be an aggregation of the data sources that are provided by the panels.rdf files described above. The names of the vendor and custom panels.rdf files could be mentioned directly in the sidebar panel definition as a composite data source. The optional panels can be added to the datasource by iterating the well-known directory in the install directory that contains the panels.rdf files installed by the user. There are no additional usability or UE features with this approach. The only changes (ignoring details) as I see it are in -- the installer, which must place the panels.rdf file for each optional feature in the correct location, and remove the correct file on uninstall of an optional feature, -- the mozilla sidebar code, which will need to construct a composite data source based on the vendor, custom, and optional component rdf files that it discovers at runtime.

Syd, I agree what we should move towards seperating the sidebar rdf files to a more componitized model. I think your proposal I think you are trying to solve only the panels.rdf (sidebar panels) where we need to solve that and the customize panels (local.rdf). I agree that we need a panels.rdf file that reflects both product specific panels in which you refer to as 1. Is this refected in the sidebar or the customize panel or the sidebar? I will assume that it in the sidebar panel it's self. All of your examples are tabs that users want to be able to remove on a profile bases. This would no make that possible. If you are talking about the customize panel then how is this rdf different then local-panel.rdf? Maybe we need code that when the sidebar url is a chrome url we need to check to see if that panel is in local-panel.rdf. If is not in there then we do not display it. Would solve the problem? For the directory of installed panels I think it would be better to be reflected in the customize panel. I would agree having this would be very useful but I would rather see it as one rdf file rather then a directory. We could extend the xpinstall API to include rginda's addPanel, and add a removePanel. If this was instead of panels.rdf then we could not refect anything that is installed on a profile bases.

Matt, seems to me the best thing to do now is to reassign this to you so that the panels.rdf/sidebar can be (scheduled to be) modified as you described. Then we can look at the installer side of this when a new "architecture" is in place.

Not sure if we (Nav team, Matt) have the time to do this in the mozilla0.9.2 timeframe. It would help if someone could take this bug.

I don't think anyone can take this bug until we decide on a plan. I had sent email asking to clarify what plan of action we want to take and I received email alluding to we where not going to do work on this bug.

I havent yet heard anything about why this has to be in mozilla0.9.2. or mozilla0.9.3. hence futuring. and nsbeta1-

vishy, you didn't ask for such reasoning, as far as I can see. Anyways, here is my understanding, gathered from the initial description: If I create a panel that needs special previlegdes but does not ship with Mozilla by default (like bookmarks panel e tc. does), I need to install it as local panel via an XPI. But in order for it to show up in the list of available panels in the sidebar customization dialog, i.e. in order to be usable at all, it has to be listed in local-panels.rdf. There is currently no good way to do that. This bug is about creating such a way.

Vishy - For monetization of the browser, we need to be able to merge sidebar information between versions. Much like our bookmarks.html issue, the business owners (Netscape.com and and International JVs) want the flexibility to merge new sidebars with the user pofile-bound selections. Also, we'd like to be able to add/merge NIM Buddy List when people upgrade, as well. Let's discuss in more detail, during our Planning meeting on Thursday.

Adding myself. We need to have this one for eMojo, per lyecies request. Msanz - Can Tao take this one, so it can be completed for eMojo?

*** Bug 93981 has been marked as a duplicate of this bug. ***

bug 93981 is different, and a lot more work than this one.

Dan - Can you pls elaborate on the differences between this bug and Bug 93981?

---> Trudelle

P2 | Major per lyecies. Let's try and get it in for 0.9.4, after all other P1 are resolved. Peter - Pls move to 0.9.4

bug 93981 describes the underlying sidebar work and is rightfully assigned to Trudelle's team. *this* bug, which is about the installer taking advantage of the future sidebar architecture, should probably stay with the install team.

OK . . . should this be re-assigned to Syd, Dan or one of the the new XPInstall team.

I'll take it back, unless Peter has a specific other person in mind.

Should this be minused? This sounds like a feature, and is targeted for 1.0

This looks like a feature we do not have time to implement at this time = PDT-

Hmm, seems this bug gets pushed and pushed along. I can understand why the target is not 1.0 any more. But why future? Does this include 1.02 or is this way beyond 1.1? Interestingly the severity is still major.

It looks to me like this bug got sidetracked! This bug is about the inability for an XPI install script to add a sidebar panel. While merging RDF files sounds like a fine idea, it is being tackled in bug 93981, and need not block this bug; web pages can call "AddPanel()" now, we just want the exact same ability from a .XPI script. Therefore I propose the following: * Create a new bug, "Expose 'Components' to XPI install.js". This is to allow XPI install scripts to create arbitary XPCOM components. See Ruth's comments already in this bug. * Mark this bug dependent on that bug. This bugs scope is then to provide some standard JS, presumably using nsISideBar at al, allowing install.js to add new panels. This may or may not be identical to the existing 'window.sidebar.AddPanel()'. * Possibly mark this bug as dependent on bug 113994, as currently AddPanel() prevents you adding chrome:// or file:// panels. The first part of this bug - exposing Components - is probably the most useful :) Thoughts?

Verbal sr=blizzard at CMU Mozdev day. 1.1 please.

Can't we just check if add sidebar is called from a chrome url? it's a qick help and helps a lot!

Can't we just check if add sidebar is called from a chrome url? it's a qick hack (typed help before, sorry) and helps a lot!

Heck, this is causing me problems with a tree on Extended Mac OS partition as well (yes, I moved my dev tree to a Mac OS Extended drive, and I'm still running into it, perhaps the h files are on a drive formatted for UFS).

Ignore above comments, bugzilla dropped me into this bug, comments were intended for another.

This bug seems to have gotten lost and/or confused by lots of interesting sub-discussions. The important feature for *this* bug (and not all the others that got swirled in) is the ability to register a chrome object as a sidebar from the XPI installer. Bug #93981 offers this summary: [#77564] would be satisfied if developers could simply add a panel to the existing user copy of panels.rdf -- it would essentially be calling the existing addPanel() code, only from within an XPInstall script [...]

The xpinstall script engine has been removed from the trunk, bugs in it are obsolete.